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From  the  Sponsor 


Training  and  Education 


One  of  my  favorite  resources  is  Webster’s  1828  Dictionary.  Unlike  any  of  our  mod¬ 
ern  dictionaries,  the  1828  version  provides  a  deeper  understanding  of  words.  I 
thought  the  1828  definition  of  education  was  quite  fitting  for  this  month’s  theme. 
Webster’s  says  that  education  comprehends  all  that  series  of  instruction  and  discipline 
which  is  intended  to  enlighten  understanding  . . .  and  fit  them  for  usefulness  in  their 
future  stations. 

A  primary  question  this  issue  attempts  to  highlight  is  do  our  educational  institutions  in  fact 
prepare  software  professionals  to  be  successful  in  their  future  stations'^  In  October  2006,  a  study  conduct¬ 
ed  by  the  Center  for  Strategic  and  International  Studies  revealed  a  significant  shortfall  in  the 
number  of  software  professionals  that  had  been  formally  educated  in  software  project  manage¬ 
ment.  The  study  indicated  that  our  industry  is  lacking  in  program  managers,  software  architects, 
systems  engineers,  and  domain  experts.  Many  industry  experts  agree  that  there  is  an  adequate 
supply  of  programmers,  but  the  pool  of  these  critical  senior  managers  and  system  experts  is 
very  limited. 

As  Department  of  Defense  (DoD)  systems  become  more  and  more  software  intensive,  soft¬ 
ware  developments  get  bigger,  more  complicated,  and  more  dependent  on  senior  software  pro¬ 
fessionals  to  get  the  project  on  the  right  path  and  keep  it  there.  Since  studies  seem  to  indicate 
that  we  are  falling  behind  in  our  attempt  to  educate  certain  pockets  of  critical  expertise  and  our 
software  projects  are  in  greater  need  of  these  same  professionals,  our  problem  is  getting  worse. 
I  hope  this  month’s  articles  will  inspire  you  to  think  about  how  you  will  address  this  trend  in 
your  organization. 

For  a  more  thorough  discussion  of  this  trend  from  the  perspective  of  aerospace  engineer¬ 
ing,  I  hope  you  will  read  The  Critical  Need  for  Software  Engineering  Education  by  Dr.  Lyle  N.  Long. 
You  will  find  more  specific  software  educational  issues  addressed  in  the  two  articles  that  follow. 
In  Using  Inspections  to  Teach  Requirements  Validation  by  Lulu  He,  Dr.  Jeffrey  C.  Carver,  and  Dr. 
Rayford  B.  Vaughn,  the  authors  share  an  experiment  that  compares  the  use  of  both  checklists 
and  Perspective-Based  Reading  to  aid  in  a  requirements  validation  exercise.  In  Integrating  Software 
Nssurance  Knowledge  Into  Conventional  Curricula  by  Dr.  Nancy  R.  Mead,  Dr.  Dan  Shoemaker,  and 
Jeffrey  A.  Ingalsbe,  the  authors  compare  the  contents  of  the  Common  Body  of  Knowledge  for 
Secure  Software  Assurance  with  the  Computing  Curricula  2005:  The  Overview  Report.  Their 
intent  is  to  map  our  security  needs  with  software-related  curricula  being  recommended  for  our 
schools. 

One  of  the  options  available  to  assist  DoD  readers  with  required  software  training  is  the 
software  curriculums  available  through  the  Air  Force  Institute  of  Technology  (AFIT);  you  can 
read  more  about  AFIT  in  Software  Engineering  Continuing  Education  at  a  Price  You  Can  Affordhy  Maj 
Christopher  Bohn,  Ph.D  You  will  find  another  thought-provoking  article  from  Roger  Stewart 
and  Lew  Priven  with  their  discussion  of  successfully  implementing  software  inspections  in  How 
to  Avoid  Software  Inspection  Eailure  and  Achieve  Ongoing  Quality,  Cost,  and  Schedule  Benefits.  We  conclude 
this  month’s  issue  with  an  insightful  article  by  Dr.  Robert  B.K.  Dewar  and  Dr.  Edmond 
Schonberg  entitled  Computer  Science  Education:  Where  Are  the  Software  Engineers  of  Tomorrow? 

It  should  be  clear  throughout  the  software  community  that  education  does  not  end  once  a 
graduate  has  a  bachelor’s  degree.  The  technology  we  work  with  continues  to  grow  at  an  astound¬ 
ing  rate.  Even  if  additional  degrees  are  not  sought,  all  professionals  need  additional  education 
to  keep  current  with  the  needs  of  the  software  community.  As  a  co-sponsor  for  CrossTalk, 
I  am  happy  to  provide  one  additional  source  for  this  education. 


Kevin  Stamey 

Oklahoma  City  Air  Eogistics  Center,  Co-Sponsor 
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Announcing  CrossTalk’s  Co-Sponsor  Team  for  2008 

Elizabeth  Starrett 
Crosstalk 


I  wish  to  express  my  continuing  gratitude  for  the  support  CrossTalkV  co-sponsors  again  provide  in  2008.  I  know 
our  readers  and  staff  appreciate  the  benefits  provided  to  the  software  community  by  the  information  made  available  as 
a  result  of  their  sponsorship.  Co-sponsor  team  members  are  identified  below  with  a  description  of  their  organi^tion. 
Please  look  for  their  contributions  each  month  in  our  From  the  Sponsor  column  found  on  page  3.  Their  organisa¬ 
tions  will  also  be  highlighted  on  the  back  cover  of  each  issue  of  CrossTalk. 


The  Honorable  John  Grimes,  Department  of 
Defense  -  Chief  Information  Officer 

The  Assistant  Secretary  of  Defense  for  Net¬ 
works  and  Information  Integration  for  the 
Department  of  Defense  Chief  Information 
Officer  (ASD[NII]/DoD-CIO)  is  the  principal 
staff  assistant  and  advisor  to  the  Secretary  on  net¬ 
works  and  net-centric  policies  and  concepts,  command  and  con¬ 
trol,  communications,  non-intelligence  space  matters,  enterprise¬ 
wide  integration  of  DoD  information  matters,  and  Information 
Technology.  Additionally,  the  DoD-CIO  has  responsibilities  for 
integrating  information  and  related  activities  and  services  across 
the  DoD  The  mission  of  the  organization  is  to  enable  Net-Centric 
operations.  NII/CIO  is  leading  the  Information  Age  transforma¬ 
tion  that  will  enhance  the  DoD’s  efficiency  and  effectiveness  by 
establishing  an  Information  on  Demand  capability.  See 
<www.dod.mil/ cio-nii>  for  more  information. 


that  meet  Fleet  needs,  providing  a  technological  edge  over  adver¬ 
saries.  See  <www.navair.navy.mil>  for  more  information. 


Kevin  Stamey,  76  SMXG  Director 

The  76th  Software  Maintenance  Group  at  the 
Oklahoma  City- Air  Logistics  Center  is  a  leader  in 
the  avionics  software  industry  that  understands 
total  system  integration.  The  center  has  a  proven 
record  of  producing  software  on  time,  on  bud¬ 
get,  and  defect-free.  Its  people  provide  the  exper¬ 
tise,  software,  weapons,  interface,  and  aircraft  systems  that  are 
fully  integrated  to  ensure  dependable  war-winning  capabilities.  Its 
areas  of  expertise  include  navigation,  radar,  weapons  and  system 
integration,  systems  engineering,  operational  flight  software,  auto¬ 
matic  test  equipment,  and  more.  For  more  information,  see 
<www.bringittotinker.com>. 


Kristen  Baldwin,  Office  of  the  Secretary  of 
Defense  -  Acquisition,Technology  and  Logistics 

The  Office  of  the  Secretary  of  Defense  for  Ac¬ 
quisition,  Technology  and  Logistics  (OSD(AT&L)) 
Software  Engineering  and  Systems  Assurance  is 
the  staff  agent  responsible  for  all  matters  relat¬ 
ing  to  DoD  software  engineering,  systems  assur¬ 
ance,  system  of  sytems  (SoS)  engineering,  and  Capability  Maturity 
Model  Integration.  Organizational  focus  areas  include  pokey,  guid¬ 
ance,  education  and  training,  acquisition  program  support,  software 
acquisition  management  and  development  techniques,  software  and 
systems  engineering  integration,  SoS  enablers  and  best  practices, 
engineering  for  system  assurance,  and  government-industry  coUab- 
oration.  See  <www.acq.osd.mil/sse/ssa>  for  more  information. 

Terry  Clark,  NAVAIR,  Systems  Engineering 
Department  -  Director,  Software  Engineering 

The  Naval  Air  Systems  Command  (NAVAIR)  has 
three  Strategic  Priorities  through  which  it  pro¬ 
duces  results  for  the  Sailor  and  the  Marine.  First 
are  its  People  that  we  develop  and  provide  tools, 
infrastructure,  and  processes  needed  to  do  their 
work  effectively.  Next,  Current  Peadiness  that  dekvers  NAVAL  avi¬ 
ation  units  ready  for  tasking  with  the  right  capabikty,  at  the  right 
time,  and  the  right  cost.  Finaky,  Future  Capability  in  the  dekvery  of 
new  aircraft,  weapons,  and  systems  on  time  and  within  budget. 


®  Capability  Maturity  Model  and  CMM  are  registered  in  the  U.S.  Patent  and  Trademark 
Office  by  Carnegie  Mellon  University. 

Team  Software  Process  are  service  marks  of  Carnegie  Mellon  University. 


Norman  LeClair,  309  SMXG  Acting  Director 

The  309th  Software  Maintenance  Group  at  the 
Ogden-Air  Logistics  Center  is  a  recognized 
world  leader  in  cradle-to-grave  systems  support, 
encompassing  hardware  engineering,  software 
engineering,  systems  engineering,  data  manage¬ 
ment,  consulting,  and  much  more.  The  division 
is  a  Software  Engineering  Institute  Software  Capabikty  Maturity 
Model®  (CMM®)  Integration  Level  5  organization  with  Team 
Software  Process^^  engineers.  Their  accreditations  also  include 
AS  9100  and  ISO  9000.  See  <www.mas.hik.a£mil>  for  more 
information. 

Joe  Jarzombek,  Department  of  Homeland 
Security  -  Director  of  Software  Assurance 

The  DHS  National  Cyber  Security  Division  serves 
as  a  focal  point  for  software  assurance  (SwA), 
faeiktating  national  pubke-private  efforts  to  pro¬ 
mulgate  best  practices  and  methodologies  that 
promote  integrity,  security,  and  rekabikty  in  soft¬ 
ware  development  and  acquisition.  Cokaborative  efforts  of  the 
SwA  community  have  produced  several  pubkely  avakable  onkne 
resources.  For  more  information,  see  the  Bukd  Security  In  Web  site 
<https://buildsecurityin.us-cert.gov>,  which  is  expanding  to 
become  the  SwA  Community  of  Practice  portal  <www.us-cert. 
gov/swa>  to  provide  coverage  of  topics  relevant  to  the  broader 
stakeholder  community. 

For  more  information  about  becoming  a  CROSSTALK 
co-sponsor,  please  contact  Elizabeth  Starrett  at  (801)  775- 
4158  or  <beth.starrett@  hill.af.mil>. 
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The  2008  CrossTalk  Editorial  Board 


Elizabeth  Starrett 
Crosstalk 

Crosstalk  proudly  presents  the  2008  CrossTalk  Editorial  Board.  Each  article  submitted  to  CrossTalk  is 
reviewed  by  two  technical  reviewers  from  the  list  below  in  addition  to  me,  CrossTalk  ^ publisher.  The  insights  from  the  board 
improve  the  readability  and  usefulness  of  the  articles  that  are  published  in  CrossTalk.  Most  reviewers  listed  have  graciously 
offered  their  own  time  to  support  CrossTalk^  technical  review  process.  We  give  very  special  thanks  to  all  those  participat¬ 
ing  in  our  2008  CrossTalk  Editorial  Board. 
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The  Critical  Need  for  Software  Engineering  Education 


Dr.  Lyle  N.  Long 
The  Pennsylvania  State  University 

Software  affects  almost  every  aspect  of  our  daily  lives  (manufacturing,  hanking,  travel,  communications,  defense,  medicine, 
research,  government,  education,  entertainment,  law,  etc. ).  It  is  an  essential  part  of  our  military  systems,  and  it  is  used 
throughout  the  civilian  sector,  including  safety-critical  and  mission-critical  systems.  In  addition,  the  complexity  of  many  of 
these  systems  has  been  growing  exponentially.  Unfortunately,  the  US.  higher  education  system  has  not  kept  pace  with  these 
needs.  Existing  undergraduate  and  graduate  science  and  engineering  programs  need  to  incorporate  more  material  on  software 
engineering.  This  is  especially  true  for  aerospace  engineering,  since  those  systems  rely  heavily  on  computation,  information,  com¬ 
munications,  and  software.  In  addition,  the  United  States  needs  more  dedicated  software  engineering  educational  programs 
and  professional  software  engineering  certification  programs. 


Software  is  everywhere,  from  cell 
phones  to  large  military  systems. 
According  to  the  National  Academy  of 
Science  [1],  ‘‘...  software  is  not  merely  an 
essential  market  commodity  but,  in  fact, 
embodies  the  economy’s  production  func¬ 
tion  itself”  The  National  Institute  of 
Standards  and  Technology  (NIST)  esti¬ 
mates  that  software  errors  cost  the  U.S. 
economy  $59.5  billion  a  year  and  software 
sales  accounted  for  $180  billion  [2]. 
Software  engineering  education  does  not 
get  the  attention  it  deserves,  even  though 
it  is  crucially  important  to  our  economy. 
The  issues  related  to  software  engineering 
as  a  discipline  and  the  debates  which  have 
occurred  over  the  years,  are  not  new  and 
are  described  in  [3,  4,  5]. 

The  list  of  software  disasters  grows 
each  year.  Some  of  the  best-known 
include  the  following:  the  Ariane  5  rocket 
(Flight  501)  [6,  7],  the  Federal  Bureau  of 
Investigation  Virtual  Case  File  system  [8], 
the  Federal  Aviation  Administration 
Advanced  Automation  System  [7,  9],  the 
California  Department  of  Motor  Vehicle 
system,  the  American  Airlines  reservation 
system,  and  many,  many  more  [7,  10].  The 
F-22  aircraft  also  had  problems  initially 
due  to  its  complex  software  systems. 
Software  disasters  cost  the  United  States 
billions  of  dollars  every  year,  and  this  may 
only  get  worse  since  future  systems  will  be 
more  complex.  Boeing  spent  roughly  $800 
million  on  software  for  the  777,  and  they 
might  need  to  spend  five  times  that  on  the 
787  [11].  Aerospace  systems  will  also 
include  some  levels  of  autonomy,  accom¬ 
panied  by  an  entirely  new  level  of  soft¬ 
ware  complexity.  To  help  prevent  future 
disasters,  we  must  have  more  software 
engineers  trained  in  rigorous  technical 
programs  that  are  on  par  with  other  engi¬ 
neering  programs.  The  United  States 


should  not  wait  until  there  is  a  disaster 
that  causes  large  numbers  of  human  casu¬ 
alties  before  it  acts.  We  do  not  currently 
have  enough  software  engineers.  We  need 
to  educate  many  more  in  the  near  future, 
especially  considering  the  large  group  of 
engineers  that  will  be  retiring  in  the  next 
10  years  [12].  In  2005,  the  average  age  of 
an  aerospace  engineer  was  54  [13].  In 
addition,  more  than  26  percent  of  the 
aerospace  workers  will  be  eligible  for 
retirement  in  2008  [14]. 

Importance  of  Software  in 
Aerospace  Systems 

The  aerospace  industry  provides  roughly 
$900  billion  in  economic  activity  and 
accounts  for  more  than  1 5  percent  of  the 
gross  domestic  product  and  supports 
more  than  15  million  high  quality  jobs  in 
the  United  States  [14].  These  aerospace 
systems  rely  heavily  on  software,  which 
has  been  called  the  Achilles  Heel  of  aero¬ 
space  systems.  There  are  numerous  anec¬ 
dotes  and  examples  that  illustrate  the 
importance  of  computing  and  software  in 
aerospace.  For  example: 

•  The  Boeing  777  has  1,280  onboard 
processors  that  use  more  than  four 
million  lines  of  software;  Ada  accounts 
for  99.5  percent  of  this  [15,  16]. 

•  The  F-22  has  more  than  two  million 
lines  of  software  onboard;  between  80 
and  85  percent  is  in  Ada  [17]. 

•  Some  Blackhawk  helicopters  have 
almost  2,000  pounds  of  wire  connect¬ 
ing  all  the  computers  and  sensors. 

•  The  wiring  harness  is  often  more  com¬ 
plex  and  more  difficult  to  design  than 
the  aircraft  structure. 

•  Some  aircraft  cannot  fly  without  their 
onboard  computers  (e.g.,  F-16  and  F- 
117). 

•  The  air  traffic  control  system  relies 


heavily  on  computers,  software,  and 
communications. 

•  Interplanetary  robotics  and  spacecraft 
perform  amazing  feats,  often  in 
extreme  environments. 

•  Autonomous,  intelligent,  unmanned 
vehicles  will  be  even  less  deterministic 
than  current  systems. 

•  Computers  are  also  important  in  the 
design  and  analysis  of  aerospace  sys¬ 
tems.  Often  this  means  using  high-per¬ 
formance,  massively  parallel  computer 
systems. 

•  Communication  systems  are  critically 
important  for  aircraft  and  spacecraft; 
this  now  includes  computer  network¬ 
ing  onboard,  to  the  ground,  and  to 
other  aerospace  vehicles. 

•  Modern  aircraft  and  spacecraft  seldom 
work  alone  —  they  are  usually  part  of  a 
system  of  systems. 

One  way  to  measure  the  need  for  soft¬ 
ware  engineers  in  the  aerospace  field  is  to 
research  existing  job  opportunities.  An 
Oct.  2006  review  of  the  Lockheed-Martin 
Corporation  Web  site  showed  they  had 
536  job  openings  for  recent  graduates, 
including  68  openings  (13  percent)  in  soft¬ 
ware  engineering  and  four  in  aerospace 
engineering.  Most  of  the  aerospace  engi¬ 
neering  job  openings  were  for  structural 
engineers  capable  of  performing  finite 
element  analyses.  It  should  be  noted  that 
they  do  hire  aerospace  engineers  in  other 
areas  as  well  (for  example,  aerospace  con¬ 
trol  experts  are  sometimes  listed  under 
embedded  systems).  The  Boeing  employ¬ 
ment  Web  page  gave  similar  results.  They 
had  298  job  openings  related  to  software. 
There  were  only  three  jobs  that  mentioned 
aerodynamics  (none  of  which  were  actually 
jobs  for  aerodynamicists).  When  searching 
the  Boeing  site  for  aerospace  engineer,  it 
returned  a  listing  of  six  open  positions  in 
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structural  engineering.  This  is  probably  an 
indication  that  aerospace  engineering  edu¬ 
cational  programs  are  concentrating  too 
much  on  the  applied  physics  of  aerospace 
engineering  and  not  enough  on  comput¬ 
ing  and  software.  We  need  to  work  with 
industry  and  the  government  to  redefine 
aerospace  engineering.  We  need  to  educate 
students  capable  of  designing  and  build¬ 
ing  the  new  aerospace  systems  that  we  will 
need  in  the  future  —  which  will  be  domi¬ 
nated  by  computing,  networking,  and 
information  systems. 

Software  Engineering  Defined 

The  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE)  defines  software  engi¬ 
neering  [3]  as  ‘hhe  application  of  a  sys¬ 
tematic,  disciplined,  quantifiable  approach 
to  the  development,  operation,  and  main¬ 
tenance  of  software.”  A  good  summary  of 
software  engineering  can  be  found  in  [1 8] . 

Software  systems  are  some  of  the 
most  complicated  things  humans  have 
ever  created.  To  design  and  build  them, 
one  needs  to  follow  processes  and  proce¬ 
dures  typical  of  other  engineering  disci¬ 
plines  [6,  19].  First,  the  requirements  need 
to  be  carefully  defined.  Then  the  architec¬ 
ture  of  the  software  system  needs  to  be 
developed.  Once  the  requirements  and 
architecture  are  defined,  one  can  begin 
code  development.  The  code  then  needs 
verification,  validation,  and  testing.  There 
are  many  ways  of  accomplishing  all  of 
these  steps  which  are  related  to  the  type  of 
life-cycle  model  used  and  the  type  of  sys¬ 
tem  developed.  In  addition,  one  needs  to 
consider  how  to  estimate  costs,  how  to 
manage  the  people,  and  how  to  monitor 
the  ethical  responsibilities  of  the  team. 
This  is  not  unlike  the  steps  required  to 
design  and  build  any  complex  system  (e.g., 
bridges,  aircraft,  and  computer  hardware). 
The  actual  code  development  or  program¬ 
ming  can  be  a  fairly  small  portion  of  the 
process  [6]. 

Most  engineers  and  scientists  do  not 
fully  appreciate  or  understand  software 
engineering.  Even  high  school  students 
think  they  can  do  software  after  they  learn 
the  basics  of  Java  or  C++  syntax.  All  too 
often,  software  engineering  is  equated 
with  programming.  This  is  like  equating 
civil  engineering  with  pouring  concrete. 
Many  people  can  pour  concrete,  but  few 
are  civil  engineers  and  can  build  large, 
technically  inspired  masterpieces.  Like¬ 
wise,  many  people  can  program,  but  few 
can  develop  large  software  masterpieces. 
It  is  not  uncommon  to  hear  people  argu¬ 
ing  about  the  merits  or  drawbacks  of  the 
different  computer  languages,  even 
though  they  are  not  well  versed  on  the  var¬ 


ious  languages.  Often,  they  simply  like  the 
language  that  they  grew  up  with  and  do 
not  appreciate  or  understand  the  others. 
These  misconceptions  are  especially 
apparent  in  discussions  regarding  Ada 
[20],  which  is  still  probably  the  best  lan¬ 
guage  to  use  for  mission-  or  safety-critical 
systems.  In  reality,  people  who  develop 
code  without  sound  software  engineering 
approaches  are  merely  hackers.  Of  course, 
programmers  are  an  essential  part  of  soft¬ 
ware  engineering,  and  talented  program¬ 
mers  are  quite  rare  and  extremely  valuable. 

Software  Engineering 
Education 

Both  the  U.S.  economy  and  national 
defense  depend  upon  software,  but  many 
of  these  large  software  systems  are  being 
developed  by  people  who  have  never  been 
formally  trained  in  software  engineering. 
While  there  are  some  incredibly  talented 
self-taught  software  engineers,  we  should 

**We  need  to  work  with 
industry  and  the 
government  to  redefine 
aerospace  engineering. 
We  need  to  educate 
students  capable  of 
designing  and  building 
the  new  aerospace 
systems  that  we  will 
need  in  the  future  ...” 

not  rely  on  the  majority  of  our  software 
engineers  being  self-taught.  We  would 
never  build  modern  aircraft  without  aero¬ 
space  engineers,  and  we  would  never  build 
bridges  or  buildings  without  civil  engi¬ 
neers.  So  why  are  we  developing  large 
software  systems  without  teams  of  for¬ 
mally  trained  and  professionally  certified 
software  engineers? 

Recently,  Dr.  John  Knight,  a  professor 
at  the  University  of  Virginia,  contrasted 
software  engineering  to  other  engineering 
disciplines  [21].  He  spoke  of  how  1,000- 
year-old  cathedrals  were  built  using  the 
best  civil  engineering  technology  of  the 
time  and  how  these  buildings  are  still 
standing.  Civil  engineering  has  evolved 
tremendously  over  the  ages,  and  now  we 
have  enormous  skyscrapers  and  spectacu¬ 


lar  bridges.  This  would  not  be  possible 
without  a  vibrant  civil  engineering  educa¬ 
tional  system,  research  programs,  and 
mentoring.  Similar  analogies  could  be 
drawn  from  other  engineering  disciplines. 
A  thousand  years  from  now,  people  will  be 
marveling  at  aerospace  engineering  mile¬ 
stones  such  as  the  Wright  Flyer,  the  SR-71 
Blackbird,  and  the  Apollo  program.  All 
were  great  engineering  projects  in  their 
day  and  are  now  in  museums.  Will  there  be 
any  software  cathedrals  to  marvel  at  1,000 
years  from  now?  Or  will  future  genera¬ 
tions  view  us  as  hackers? 

Traditional  Science  and  Engineering 
Educational  Programs 

Many  students  who  graduate  from  U.S. 
science  and  engineering  programs  will 
eventually  work  in  software  development. 
Unfortunately,  most  of  them  will  get  little 
or  no  software  education.  For  example,  24 
percent  of  physics  graduates  will  be  work¬ 
ing  on  software  five  to  eight  years  after 
graduation  [22].  Most  of  them  will  proba¬ 
bly  receive  no  training  in  software  engi¬ 
neering  in  college.  Other  science  gradu¬ 
ates,  even  outside  of  engineering,  may 
also  eventually  work  in  software  develop¬ 
ment.  It  would  be  very  beneficial  for  these 
students  to  know  more  about  software 
engineering  before  they  graduate.  They 
need  more  than  a  freshman-level  course 
in  programming.  This  is  true  of  almost  all 
the  traditional  science  and  engineering 
degree  programs. 

It  is  also  not  valid  to  assume  that  com¬ 
puter  science  graduates  are  software  engi¬ 
neers,  either.  It  is  fairly  easy  to  graduate 
from  a  computer  science  program  with 
very  little  education  in  software  develop¬ 
ment.  Knight  and  Leveson  describe  the 
need  for  more  software  education  in  com¬ 
puter  science  and  computer  engineering 
programs  and  advocate  for  more  software 
engineering  programs  [23] . 

The  need  for  software  education  is 
especially  critical  in  aerospace  engineering 
programs.  Aerospace  engineers  have 
always  prided  themselves  on  being  the 
system  integrators,  but  to  do  this  you 
must  have  some  understanding  of  the 
complete  aerospace  system  you  are  devel¬ 
oping.  In  modern  combat  aircraft,  the 
electronic  components  account  for 
roughly  10  percent  of  the  weight  and  33 
percent  of  the  cost  [24].  So  if  aerospace 
engineers  are  not  well  versed  in  comput¬ 
ing,  networking,  sensors,  and  software 
then  they  cannot  understand  the  complete 
system  (unless  that  system  is  60  years  old). 
Students  need  to  be  trained  so  that  they 
can  develop  the  next  generation  of  aero¬ 
space  systems,  not  old  aircraft  and  old 
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Spacecraft.  Aerospace  systems  have 
always  used  the  latest  technology  to 
achieve  amazing  performance.  Future 
and  current  systems  rely  heavily  on  com¬ 
puters  and  software  and  students  need  to 
know  that.  Aerospace  engineers  are 
needed  as  system  integrators,  but  this  is 
only  possible  if  they  have  some  under¬ 
standing  of  the  complete  system  (includ¬ 
ing  computing  and  software). 

Today  this  goes  beyond  the  onboard 
avionics  since  modern  aircraft  and 
spacecraft  are  almost  always  tied  to  other 
systems,  but  avionics  is  a  huge  part  of 
aerospace  systems.  Processing  power 
and  computer  memory  have  been 
increasing  exponentially  in  military  air¬ 
craft  since  about  1960  [25].  The  F-106 
had  less  than  20  kilobytes  of  memory, 
while  the  Joint  Strike  Fighter  (JSF)  could 
have  more  than  two  gigabytes.  Avionics 
could  account  for  40  percent  of  the  cost 
of  the  JSF.  The  report  also  states  that 
software  content  in  these  systems  has 
increased  dramatically,  and  that  we  need 
more  software  engineers. 

Computing  and  software  are  integral 
parts  of  aerospace  engineering.  It  is  now 
one  of  the  key  disciplines  in  aerospace 
engineering.  Traditionally,  aerospace 
engineering  [26]  was  built  upon  four 
technology  pillars',  aerodynamics,  struc¬ 
tures,  propulsion,  and  dynamics  and 
control,  as  shown  in  Figure  1 .  These  pil¬ 
lars  are  reflected  in  aerospace  engineer¬ 
ing  curricula.  All  these  disciplines  were 
important  for  the  Wright  brothers  and 
for  every  aerospace  system  since  then. 
However,  modern  aerospace  engineering 
must  include  five  pillars,  as  shown  in 
Figure  2.  In  [27],  the  authors  refer  to  the 
five  areas  as  the  following:  aerodynam¬ 
ics,  materials,  avionics,  propulsion,  and 
controls.  Current  and  future  aerospace 
systems  are  and  will  be  designed  using 
computers.  They  will  have  onboard 
computers  and  will  need  to  communi¬ 
cate  with  other  vehicles  and  computers. 


Figure  1 :  Old  Aerospace  Engineering 
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Computing  (including  processing,  net¬ 
working,  and  storing  data)  and  software 
are  essential  elements  of  aerospace  engi¬ 
neering,  and  they  are  the  fifth  pillar.  In 
addition,  this  fifth  pillar  might  be  the 
most  important  pillar,  and  it  is  far  less 
mature  than  the  other  four.  Aerospace 
engineering  educational  programs  have  a 
strong  emphasis  on  applied  physics  (e.g, 
fluid  dynamics,  structural  dynamics, 
dynamics,  combustion,  and  propulsion). 
Historically,  there  were  good  reasons  for 
this,  but  we  cannot  continue  to  neglect 
the  research  and  educational  needs  in 
aerospace  computing  and  software. 

‘^While  computing  and 
software  is  crucial  for 
aerospace  systems, 
existing  aerospace 
engineering  educational 
programs  usually  do  not 
reflect  this  fact.*^ 

While  computing  and  software  is 
crucial  for  aerospace  systems,  existing 
aerospace  engineering  educational  pro¬ 
grams  usually  do  not  reflect  this  fact. 
Most  aerospace  engineering  programs 
require  roughly  40  courses  over  a  four- 
year  period,  but  students  often  take  only 
one  course  related  to  software  (a  fresh- 
man-level  programming  course).  Also, 
there  is  usually  no  requirement  to  learn 
about  avionics,  embedded  systems,  net¬ 
working,  sensors,  or  computer  hardware. 
This  trend  carries  through  to  aerospace 
engineering  graduate  programs  as  well, 
where  the  entrance  exams  and  curricula 
seldom  include  computing,  software,  or 
avionics.  They  are  often  primarily 

Figure  2:  Modern  Aerospace  Engineering 
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applied  physics  programs. 

Pennsylvania  State  University  has 
been  working  to  modernize  its  aerospace 
engineering  curricula  [28].  The  universi¬ 
ty  now  offers  senior-level  courses  in 
advanced  computer  programming 
(object-oriented  programming,  Java, 
C++,  Ada,  etc.)  and  software  engineer¬ 
ing  (using  [6]),  both  for  aerospace  engi¬ 
neers.  Penn  State  also  has  a  new  course 
on  the  Global  Positioning  System.  As  of 
2006,  aerospace  engineering  students 
will  be  required  to  take  either  the  software 
engineering  course  or  an  electronic  cir¬ 
cuits  course.  Ideally,  they  should  take 
both  and  also  be  exposed  to  systems 
engineering,  embedded  systems,  net¬ 
working,  information  systems,  sensors, 
and  software.  These  additional  topics 
could  be  covered  in  their  technical  elec¬ 
tives  or  in  graduate  courses.  Some  of 
them  could  be  covered  in  a  minor  also. 
The  university  also  hopes  to  establish  an 
undergraduate  minor  in  information  sci¬ 
ences  and  technology  for  aerospace 
engineering  in  2008. 

It  should  also  be  noted  that  it  is  dif¬ 
ficult  to  teach  an  engineer  all  they  need 
to  know  in  four  years.  In  fact,  the  U.S. 
National  Academy  of  Engineering  [29] 
recommends  that  the  bachelor  of  sci¬ 
ence  degree  be  recognized  as  a  pre-engi¬ 
neering  degree.  Scientists  and  engineers 
need  to  continue  learning  throughout 
their  lifetimes  to  be  effective.  In  addi¬ 
tion,  many  aerospace  engineering  posi¬ 
tions  require  a  master’s  degree,  which 
allows  the  student  to  concentrate  on  a 
particular  area.  An  excellent  combina¬ 
tion  would  be  for  a  student  to  get  a 
bachelor  of  science  in  aerospace  engi¬ 
neering  and  then  a  master’s  degree  or 
doctorate  in  software  (or  systems)  engi¬ 
neering.  These  graduates  would  be 
extremely  valuable.  Another  possibility  is 
to  offer  an  undergraduate  or  graduate 
minor  in  software  engineering.  Penn 
State  has  a  popular  graduate  minor  in 
computational  science,  which  attracts 
students  from  a  wide  variety  of  science 
and  engineering  departments  [30].  A 
similar  program  could  be  created  for 
software  engineering  or  systems  engi¬ 
neering. 

Dedicated  Software  Engineering 
Education  Degree  Programs 

As  previously  stated,  existing  science 
and  engineering  education  programs 
need  to  include  more  computing  and 
software  in  their  curricula,  but  they  also 
need  more  dedicated  software  engineer¬ 
ing  programs.  These  software  engineer¬ 
ing  programs,  however,  need  to  include 
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plenty  of  science  and  engineering  in 
their  curricula  (e.g.,  physics,  mathemat¬ 
ics,  and  embedded  systems).  They 
should  not  have  an  overemphasis  on 
management,  business,  and  processes. 
The  Association  for  Computing 
Machinery  (ACM),  the  IEEE,  and  the 
National  Science  Foundation  have  devel¬ 
oped  very  good  undergraduate  curricula 
in  software  engineering  [3]. 

Currently  in  the  United  States,  there 
are  only  10  accredited  software  engineer¬ 
ing  undergraduate  programs  [31],  while 
there  are  67  aerospace  engineering  pro¬ 
grams.  The  United  States  needs  many 
more  software  engineering  programs. 
This  needs  to  happen  soon,  since  it  takes 
years  to  start  new  programs  and  for  stu¬ 
dents  to  graduate.  In  addition,  the 
United  States  has  an  aging  workforce. 
Some  companies  in  the  aerospace  and 
defense  business  could  see  40  percent  of 
their  workforce  retire  in  the  next  five 
years  [12].  According  to  the  Wall  Street 
Journal,  organizations  such  as  the 
National  Aeronautics  and  Space 
Administration  have  more  engineers 
over  60  than  under  30. 

In  addition  to  the  existing  undergrad¬ 
uate  software  engineering  programs, 
there  are  109  software  engineering  mas¬ 
ter’s  degree  programs  and  40  software 
engineering  doctorate  programs  in  the 
United  States.  Few  of  the  undergraduate 
or  graduate  programs,  however,  are  at 
major  research  universities.  In  addition, 
few  of  them  exist  at  universities  includ¬ 
ed  in  the  top  25  schools  listed  in  the  U.S. 
Nem  and  World  Keport  rankings.  Most  of 
these  programs  are  at  relatively  small 
schools,  maybe  because  they  are  able  to 
react  more  quickly  to  industry  and  soci¬ 
ety  needs. 

Unfortunately,  change  occurs 
extremely  slowly  in  academia  because 
there  are  few  incentives  to  change. 
Government  funding  could  and  should 
be  used  to  help  expedite  these  changes. 
Industry  leaders  need  to  get  involved 
and  demand  change  as  well.  There  needs 
to  be  internships  and  mentoring  avail¬ 
able.  There  is  also  a  need  for  continuing 
education.  At  the  government  labs  and 
in  industry,  there  is  a  huge  need  for  soft¬ 
ware  engineering  training  for  its  existing 
workforce. 

We  also  need  software  engineering 
professional  certification.  The  IEEE  has 
developed  an  excellent  Certified 
Software  Development  Professional 
(CSDP)  program  [32,  33].  This  is  a  great 
program,  but  it  is  not  quite  a  software 
engineering  certification  program. 
Unfortunately,  there  is  no  requirement 


for  a  science  or  engineering  background 
for  the  certification,  so  it  is  not  the  same 
as  other  professional  engineering  certifi¬ 
cation  programs.  In  addition,  at  the  time 
this  article  was  written,  there  were  only 
575  people  in  the  world  who  have  the 
CSDP  certification.  Beginning  in  1999, 
Texas  began  certifying  software  engi¬ 
neers  [34].  In  addition,  the  Open  Group 
has  established  an  information  technolo¬ 
gy  architect  certification  program  [35]. 

Conclusion 

Higher  education  in  the  United  States 
needs  to  be  more  responsive  to  the  soft¬ 
ware  engineering  needs  of  its  industry 
and  government  labs.  The  United  States 
cannot  be  complacent  with  its  techno¬ 
logical  leads  in  any  field,  especially  soft¬ 
ware  and  aerospace,  which  are  two  of 
the  most  important  industries  in  its 
economy.  These  two  industries  annually 
provide  more  than  $180  billion  and  |900 
billion,  respectively,  to  the  economy. 
Technology  has  been  changing  at  an 
exponential  rate,  and  too  often  curricula 
changes  extremely  slowly.  Software  engi¬ 
neering  needs  to  be  incorporated  into 
existing  science  and  engineering  pro¬ 
grams,  especially  aerospace  engineering 
curricula.  We  also  need  to  create  more 
dedicated  software  engineering  educa¬ 
tional  programs  at  all  levels  —  short 
courses,  bachelors,  masters,  and  doctorate 
levels.  And  finally,  there  also  needs  to  be  a 
national  effort  to  develop  professional 
certification  of  software  engineers. ♦ 
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Letter  to  the  Editor 


Dear  CrossTalk  Editor, 

Once  again,  the  cover  for  CrossTalk 
is  a  knockouA  Congratulations  to  the  staff 
and  to  the  editor  for  a  great  edition.  I 
was  wondering  when  systems  engineer¬ 
ing  would  be  a  transitional  topic  about 
systems  engineering  and  software  inclu¬ 
sion. 

When  I  stepped  down  from  the  prin¬ 
cipal  investigator  position  on  the  B-IB 
program,  I  went  into  software  because 
of  the  lack  of  understanding  I  found 
between  systems  engineering  and  soft¬ 
ware.  Due  to  my  relationship  with  the 
company’s  system  engineering  manager 
and  the  software  manager  —  and  the  help 
of  CrossTalk  articles  that  I  sent 
them  —  they  finally  decided  to  have  meet¬ 
ings  in  their  manager’s  office  and  talked 
together!  What  a  milestone  that  was!  I 
still  send  CrossTalk  articles  to  these 
guys,  which  they  are  grateful  for  because 
it  helps  keep  them  current  on  industry 


thinking. 

This  edition  should  be  given  to  every 
systems  engineer  manager  and  staff,  as 
well  as  software  managers.  Let’s  get  the 
communication  going  among  our  con¬ 
tractors! 

I  could  not  have  been  more  pleased 
with  Dr.  John  W  Fischer’s  introduction 
in  the  Sponsor’s  Note  to  this  month’s 
issue  of  CrossTalk.  His  remarks  are 
dead-on  regarding  the  issues  and  evolution 
of  system  engineering  with  software. 
Gee,  can  you  imagine  what  the  founda¬ 
tion  for  requirements  would  start  to  look 
Hke? 

Thanks  for  another  great  issue! 

-  Melonee  Moses 

Software/Logistics  Management  Specialist 
DCMA  Boeing 
Long  Beach,  CA 
<melonee.moses@dcma.mil> 
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Using  Inspections  to  Teach  Requirements  Validation 


Lulu  He,  Dr.  Jeffrey  C.  Carver,  and  Dr.  Rayford  B.  Vaughn 

Mississippi  State  University 

Requirements  validation  is  often  not  adequately  covered  by  a  traditional  software  engineering  curriculum  in  universities.  This 
article  describes  an  experiment  conducted  in  a  graduate-level  requirements  engineering  course  to  provide  students  a  real  world 
experience  in  requirements  validation.  The  experiment  made  use  of  the  N-fold  inspection  method,  in  which  multiple  teams  of 
students  inspect  the  same  requirements  document  then  meet  together  to  discuss  their  findings.  This  procedure  allows  the  stu¬ 
dents  to  not  only  practice  their  reviewing  skills,  but  also  to  strengthen  their  communication  and  collaboration  skills.  Mt  the 
conclusion  of  the  exercise,  the  students  were  given  the  opportunity  to  provide  qualitative  and  quantitative  feedback.  The  results 
of  this  study  suggest  that  the  techniques  employed  by  this  class  and  the  resulting  defect  detection  could  be  useful  in  general  dur¬ 
ing  the  requirements  validation  process. 


It  can  be  argued  that  requirements  engi¬ 
neering  (RE)  is  one  of  the  most  impor¬ 
tant  stages  in  a  traditional  software  devel¬ 
opment  life  cycle  because  it  helps  to  cor¬ 
rectly  determine  the  desired  purpose  of  a 
system.  The  goal  of  an  RE  process  is  to 
identify  and  document  stakeholders  and 
their  needs  in  a  form  amenable  to  analy¬ 
sis,  communication,  and  implementation 
[1].  Correct,  complete,  and  unambiguous 
requirements  not  only  ensure  that  devel¬ 
opers  build  the  right  system,  but  also 
reduce  the  effort  and  cost  that  would 
otherwise  be  needed  to  fix  requirements 
problems  later.  Because  of  the  impor¬ 
tance  in  obtaining  correct  requirements, 
RE  courses  are  fundamental  elements  of 
any  software  engineering  curriculum.  An 
RE  course  should  teach  students  tech¬ 
niques  for  accurately  eliciting,  analyzing, 
and  validating  requirements.  By  acquiring 
these  skills,  future  software  engineers  are 
better  equipped  to  produce  quality 
requirements,  eliminate  faults,  and  reduce 
development  time.  Educating  students  in 
RE,  however,  is  not  an  easy  task  because 
it  is  a  human-centered  process  that  re¬ 
quires  skills  from  a  variety  of  disciplines 
(e.g.,  computer  science,  system  engineer¬ 
ing,  cognitive  psychology,  anthropology, 
and  sociology)  [1].  Moreover,  RE  educa¬ 
tors  must  bridge  the  gap  between  acade¬ 
mia  and  industry  by  exposing  students  to 
the  real  world  as  much  as  possible.  One 
important  real-world  aspect  of  RE  that 
has  remained  largely  unstudied  in  the 
software  engineering  education  commu¬ 
nity  is  requirements  validation. 

This  article  describes  an  exercise  to 
aid  in  the  teaching  of  requirements  vali¬ 
dation  in  a  graduate-level  RE  course, 
along  with  an  evaluation  of  its  usefulness. 
In  the  exercise,  the  students  validated  a 
real  software  requirements  specification 
document  provided  by  an  industrial  part¬ 
ner  using  a  meeting-based  N-fold  inspec¬ 
tion  method  (described  later)  [2]. 


Background 

Previous  research  has  identified  challenges 
faced  during  RE  education.  Because  one 
goal  of  software  engineering  education  is 
to  help  students  develop  the  knowledge 
and  skills  necessary  to  be  successful  in 
industry,  a  challenge  for  RE  educators  is 
that  the  inherent  complexity  of  industrial 
RE  (i.e.  the  broad  scope,  multiple  con¬ 
cerns,  and  deficient  specifications)  is  diffi¬ 
cult  to  replicate  in  a  classroom  environ¬ 
ment  [3,  4].  To  be  successful,  a  require¬ 
ments  engineer  must  possess  both  the 
technical  skills  needed  to  interact  with  the 
system  and  the  social  skills  needed  to 
interact  with  its  human  stakeholders  [1]. 
These  soft  skills  (e.g.,  communication  and 
teamwork)  are  also  difficult  to  teach  in  the 
classroom  [5]. 

Most  published  work  on  RE  education 
has  focused  on  a  small  set  of  RE  topics: 
elicitation,  analysis,  and  the  overall  process. 
Validation  is  a  complex  task  that  is  often 
not  adequately  covered  in  a  traditional  uni¬ 
versity  education  [6] .  A  requirements  docu¬ 
ment  can  have  many  different  types  of  defi¬ 
ciencies  that  may  have  disastrous  effects  on 
subsequent  development  stages  and  yield 
undesirable  consequences  [4,  7].  The 
requirements  validation  process  checks  for 
different  types  of  problems  (e.g.,  omis¬ 
sions,  inconsistencies,  and  ambiguities)  to 
help  ensure  that  proper  quality  standards 
are  fulfilled.  Due  to  time  limits  and  other 
considerations,  validation  is  usually  con¬ 
ducted  informally  either  on  an  ad-hoc  basis 
or  simply  as  a  peer  review  [8].  As  a  result, 
little  has  been  reported  concerning  the  edu¬ 
cational  challenges  of  validation  topics  kke 
inspections.  These  challenges  highlight  the 
importance  of  improving  education  and 
critical,  technical,  and  social  skills  that  a 
requirements  engineer  must  possess. 
However,  the  topics  covered  in  many  soft¬ 
ware  engineering  courses  do  not  meet  these 
needs,  posing  a  major  challenge  for  devel¬ 
oping  RE  skills  [6,  9].  Furthermore,  experi¬ 


ence  reports  about  RE  education  is  rare  in 
software  engineering  and  RE  literature.  To 
address  the  lack  of  focus  on  requirements 
validation,  we  developed  a  requirements 
validation  exercise  which  we  found  to  be 
successful  and  instructive.  This  exercise  is  a 
follow-on  experiment  from  that  reported  at 
the  Fourteenth  Annual  Systems  and 
Software  Technology  Conference  held  in 
Salt  Lake  City  in  April  2002  titled  ‘‘Third 
Party  Walkthrough  Inspections:  A  Joint 
Navy/ University  Empirical  Software 
Engineering  Project.”  The  most  recent 
results  of  the  experiment  were  also  pre¬ 
sented  by  invitation  at  the  Canadian  Air 
Force  Software  Engineering  Symposium 
held  at  the  Royal  Military  College  of 
Canada  in  Kingston,  Ontario,  May  2007 
[10,  11]. 

Description  of  the 
Requirements  Validation 
Exercise 

The  exercise  was  conducted  during  a  grad¬ 
uate-level  RE  course  at  Mississippi  State 
University.  The  class  included  graduate  stu¬ 
dents  that  were  currently  working  for  the 
Department  of  Defense  (DoD),  had  previ¬ 
ous  government  software  development 
experience,  and  many  that  had  no  practical 
experience.  The  main  goal  of  this  course 
was  to  provide  students  with  a  comprehen¬ 
sive  overview  of  requirements  elicitation, 
analysis,  specification  validation,  and  man¬ 
agement.  These  activities  were  introduced 
in  the  context  of  systems  engineering  and 
various  software  development  life-cycle 
models.  For  each  activity,  the  students  were 
exposed  to  specific  methods,  tools,  and 
notations.  The  semi -weekly,  75-minute 
class  sessions  contained  a  mixture  of  lec¬ 
ture  material,  class  discussions  centered  on 
outside  readings,  and  student  presentations. 
Near  the  end  of  the  semester,  the  students 
participated  in  a  two-week  requirements 
validation  exercise  —  the  primary  subject  of 
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this  article.  While  the  exercise  reported 
here  is  based  on  a  small  number  of  stu¬ 
dents,  we  believe  the  results  achieved  sug¬ 
gest  that  such  techniques  could  be  consid¬ 
ered  in  larger  requirements  validation  exer¬ 
cises.  The  authors  are  amenable  to  cooper¬ 
ating  with  others  to  expand  this  research 
through  additional  empirical  investigation 
-  particularly  in  DoD  software  engineering 
endeavors. 

Overview  and  Goals  of  the 
Requirements  Validation  Exercise 

The  overall  goal  of  the  exercise  was  to  pro¬ 
vide  students  with  hands-on  practice  in 
requirements  validation.  The  specific  goals 
of  the  requirements  validation  exercise 
were  the  following: 

1 .  To  help  students  understand  the  course 
materials  better  by  experiencing  the  for¬ 
mat  and  presentation  of  a  real  require¬ 
ments  document,  experiencing  the 
impact  of  domain- specific  language  in 
understanding  and  reviewing  a  require¬ 
ments  document,  and  exposing  the  stu¬ 
dents  to  flaws  commonly  found  in  a 
requirements  document. 

2.  To  help  students  obtain  an  appreciation 
for  the  complexity  and  necessity  of  RE, 
especially  requirements  validation. 

3.  To  give  students  hands-on  experience 
validating  a  requirements  document 
with  specific  inspection  techniques. 

4.  To  provide  an  opportunity  for  students 
to  practice  sh7/s  such  as  communi¬ 
cation  and  teamwork. 

Two  important  goals  of  the  course 
were  addressed  through  this  exercise.  First, 
give  the  students  an  idea  of  the  size,  com¬ 
plexity,  language,  and  flaws  that  can  occur 
in  software  artifacts,  they  validated  a  real 
requirements  document,  which  was  actual¬ 
ly  used  by  a  contractor  to  develop  and 
implement  a  system.  The  requirements 
document  described  an  upgrade  to  a  case¬ 
tracking  system  for  the  U.S.  National  Labor 
Relations  Board.  The  43-page  document 
was  written  in  natural  language  (English) 
and  contained  the  standard  content  that 
would  be  expected  in  a  government 
requirements  document. 

Second,  to  expose  students  to  a  real- 
world  requirements  validation  method,  the 
N-fold  inspection  method  was  used.  In  this 
method,  the  same  artifact  is  inspected  by 
multiple  teams  in  parallel  with  the  goal  of 
improving  the  overall  review  effectiveness 
[12].  From  an  educational  point  of  view, 
the  N-fold  inspection  method  provides 
students  with  an  opportunity  to  discuss  the 
defects  found  with  other  students,  thereby 
understanding  how  others  had  viewed  the 
artifact.  Furthermore,  N-fold  inspection 


meetings  expose  students  to  the  impor¬ 
tance  of  communication  and  teamwork  — 
important  soft  skills. 

Requirements  Validation  Techniques 

Studies  have  shown  that  inspections  are  an 
effective  requirements  validation  tech¬ 
nique  because  they  greatly  improve  system 
quality  by  detecting  many  defects  early  in 
the  software  life  cycle  [13].  Within  the  N- 
fold  method,  individual  reviewers  can  use 
different  approaches  to  review  the  docu¬ 
ment.  Our  students  used  either  a  checklist 
approach  or  the  Perspective-Based 
Reading  (PBR)  approach  (each  described 
in  more  detail). 

In  practice,  most  industrial  inspections 
use  an  ad-hoc  or  checklist-based  approach 
for  defect  detection  [14].  A  checklist  pro¬ 
vides  the  inspector  with  concrete  guidance 
that  is  not  provided  by  an  ad-hoc 
approach.  A  checklist  is  a  list  of  items  that 
focus  an  inspector’s  attention  on  specific 
topics,  such  as  common  defects  or  organi¬ 
zational  rules,  while  reviewing  a  software 


**Studies  have  shown 
that  inspections  are  an 
effective  requirements 
validation  technique  ...  by 
detecting  many  defects 
early  in  the 
software  life  cycled^ 


document  [15].  For  this  requirements  vali¬ 
dation  exercise,  an  informal  checklist  was 
developed  that  focused  on  important  qual¬ 
ity  concepts  relevant  to  a  requirements 
document.  Checklist  examples  are  readily 
available  on  the  Web,  for  example,  <soft- 
ware.gs  fc.nasa.gov  /  As  sets  Approved  /  PA2 . 
2.1.5.doc>,  <www.processimpact.com/ 
process_assets  /  requirements_review_ 
checklist.doc>,  or  <www.swqual.com/ 
training/Require.pdf>.  For  the  class  exer¬ 
cise,  we  used  a  checklist  based  on  the 
Volere  Requirements  Specification  Tem¬ 
plate  which  can  be  found  at  <www. 
systemsguild.com  /  GuildSite  /  Robs /Tern 
plate.html>. 

PBR  is  a  systematic  inspection  tech¬ 
nique  that  supports  defect  detection  in 
software  requirements  through  a  role- 
playing  exercise  [13].  In  PBR,  each 
reviewer  verifies  the  correctness  of  the 
requirements  from  the  perspective  of  a 
specific  stakeholder.  The  most  common 


perspectives  are  the  user,  the  designer, 
and  the  tester.  PBR  techniques  provide 
reviewers  with  a  set  of  steps  to  follow  to 
build  a  high-level  system  abstraction  and 
questions  to  help  identify  problems.  For 
example,  a  reviewer  assuming  the  user 
perspective  may  create  use  cases,  while  a 
reviewer  assuming  the  tester  perspective 
would  create  test  plans.  Studies  have 
shown  that  PBR  is  a  more  effective,  sys¬ 
tematic,  focused,  goal-oriented,  customiz¬ 
able,  and  transferable  process  than  a  stan¬ 
dard  checklist  or  ad-hoc  approach  [1 6] .  By 
reviewing  the  requirements  document 
from  the  perspective  of  different  stake¬ 
holders  (i.e.,  playing  the  role  of  that  stake¬ 
holder),  the  reviewers  are  expected  not 
only  to  detect  more  defects,  but  also  to 
better  comprehend  the  complexity  of  RE. 

Details  of  the  Requirements 
Validation  Exercise  and  Summary  of 
Research  Results 

Students  enrolled  in  the  course  were 
divided  into  four,  three-person  teams  with 
the  expertise  level  balanced  across  teams. 
The  members  of  two  teams  used  a  check¬ 
list  to  inspect  the  requirements  document, 
while  members  of  the  other  two  teams 
used  the  PBR  technique.  For  the  PBR 
teams,  each  student  was  instructed  to  use 
one  of  the  three  perspectives  (user, 
designer,  or  tester)  to  guide  their  inspec¬ 
tion.  These  two  inspection  techniques 
were  chosen  because  research  suggested 
that  while  PBR  is  often  a  more  effective 
technique,  checklists  are  more  widely  used 
in  government  and  industry  [14].  A  sec¬ 
ond  motivator  was  that  no  previous  work 
had  compared  the  effectiveness  of  a 
checklist-based  approach  to  the  effective¬ 
ness  PBR  in  the  context  of  the  N-fold 
inspection  method.  More  importantly, 
instead  of  using  a  generic  checklist,  the 
checklist  in  this  study  was  specifically 
developed  for  the  type  of  requirements 
document  to  be  inspected  (e.g.,  from  a 
government  organization). 

Before  the  exercise  began,  the  stu¬ 
dents  received  one  class  meeting  (75  min¬ 
utes)  of  training  in  their  assigned  tech¬ 
nique  (checklist  or  PBR).  The  training  for 
the  checklist  teams  was  done  through  a 
discussion  with  the  course  professor 
about  attributes  of  requirements  quality. 
During  this  discussion,  the  checklist  stu¬ 
dents  —  heavily  guided  by  the  professor  — 
developed  a  checklist  to  guide  their 
inspection.  The  training  for  PBR  was 
done  by  an  expert  in  PBR  and  included  a 
discussion  of  the  theory  behind  the  tech¬ 
niques  and  a  case  study  that  illustrated  an 
example  of  its  use.  After  the  training,  the 
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PBR  reviewers  were  given  the  detailed  pro¬ 
tocol  for  their  assigned  perspective.  Then 
each  student  performed  an  individual 
inspection  of  the  requirements  document 
using  their  assigned  technique.  During  this 
inspection,  each  student  individually 
reviewed  the  document  and  recorded  as 
many  defects  as  he  or  she  could  find.  The 
students  were  given  two  days  to  perform 
this  task  outside  of  class.  Once  all  three 
members  of  a  team  completed  the  individ¬ 
ual  inspection  step,  they  met  together  in 
the  1st  Team  Meeting.  During  this  meet¬ 
ing,  the  students  discussed  the  defects  they 
found  and  agreed  on  a  final  team  defect 
list.  After  all  four  teams  had  conducted  the 
1  St  Team  Meeting,  the  two  checklist  teams 
(six  students)  met  together  and  the  two 
PBR  teams  (six  students)  met  together  for 
the  2nd  Team  Meeting.  In  these  six-person 
meetings,  the  reviewers  examined  the  two 
defect  lists  produced  during  the  1st  Team 
Meeting  and  agreed  on  a  final  list  of 
defects. 

The  data  analysis  indicated  that  PBR 
was  more  effective,  both  for  individual 
inspectors  and  for  the  teams.  Conversely, 
the  data  suggested  that  the  checklist  teams 
had  more  effective  team  meetings  during 
the  N-fold  inspection  process  than  the 
PBR  teams.  Here,  the  effectiveness  of 
team  meetings  is  defined  by  two  mea¬ 
sures:  meeting  gains ^  i.e.  the  number  of 
defects  identified  during  the  meeting  dis¬ 
cussions  that  no  individual  inspector  had 
found  prior  to  the  meeting,  and  meeting 
losses^  i.e.  defects  found  by  an  individual 
inspector  that  the  inspection  team  deter¬ 
mines  are  false  positives  and,  hence,  not 
recorded  on  the  final  team  defect  list.  In 
the  case  of  the  PBR  teams,  the  team 
meeting  served  little  purpose  because 
there  were  few  meeting  gains  or  meeting 
losses.  The  end  result  would  have  been 
similar  had  the  individual  list  simply  been 
combined  without  spending  time  in  a  for¬ 
mal  team  meeting.  Conversely,  for  the 
checklist  teams,  the  meeting  served  a  vital 
role  in  the  process.  During  the  team  meet¬ 
ings,  not  only  were  there  meeting  gains, 
but  also  a  large  percentage  of  false  posi¬ 
tives  were  identified  and  removed  as 
meeting  losses.  Identification  of  false 
positives  saves  time  during  the  rework 
phase.  One  likely  cause  of  this  result  is 
the  different  perspectives  from  which  the 
PBR  reviewers  approached  the  Software 
Requirements  Specification  (SRS).  Each 
PBR  reviewer  focused  on  their  own  per¬ 
spective  and  was  less  concerned  with  the 
perspectives  of  others.  For  the  checklist 
team,  the  reviewers  inspected  the  SRS 
using  the  same  checklist  and  there  was 
more  interaction  among  team  members 


during  the  meetings.  The  most  important, 
and  novel,  conclusion  drawn  from  these 
results  is  that  the  effectiveness  and  neces¬ 
sity  of  a  team  meeting  depends  greatly  on 
the  technique  used  during  the  individual 
preparation  phase  of  the  inspection. 
Additional  data  on  this  experiment  can  be 
obtained  by  contacting  the  second  or 
third  author  of  this  article. 

Evaluation  of  the  Educational  Value 
of  the  Exercise 

To  evaluate  the  effectiveness  of  this  exer¬ 
cise  relative  to  the  four  educational  goals 
listed  earlier,  quantitative  and  qualitative 
data  was  collected  using  a  post- study  sur¬ 
vey.  Goals  1-3  were  specifically  evaluated 
by  the  survey  questions  in  Table  1  (see 
page  14).  Goal  4  was  addressed  by  using 
team  meetings,  but  it  was  not  specifically 
evaluated  on  the  post-study  questionnaire. 
The  survey  focused  on  the  students’  opin¬ 
ions  of  the  exercise  and  gave  them  an 
opportunity  to  provide  feedback  on  how 
to  improve  the  exercise.  The  first  two 
questions  were  answered  using  a  predeter¬ 
mined  scale  (explained  with  each  ques¬ 
tion).  The  other  questions  were  answered 
using  free  text. 

Results 

This  section  discusses  the  results  from  the 
post-exercise  questionnaire  along  with  a 
brief  explanation.  The  questionnaire  col¬ 
lected  both  qualitative  and  quantitative 
data  from  the  students. 

Quantitative  Data 

Ql.Was  the  exercise  a  positive  or  nega¬ 
tive  experience? 

The  students  answered  this  question  on  a 
scale  of  1  (negative)  to  5  (positive).  Figure 
1  shows  that  91  percent  of  the  students 
found  the  exercise  to  be  a  positive  experi¬ 


Figure  1 :  Positive  or  Negative  Experience 
Results 


ence  with  no  students  having  a  negative 
experience.  In  Figure  1,  the  ratings  given 
by  students  using  PBR  and  checklist  are 
shown  in  different  shades  to  evaluate  any 
impact  the  technique  had.  While  the  opin¬ 
ion  of  the  PBR  reviewers  is  slightly  more 
positive,  there  is  little  difference  due  to  the 
technique  used.  Therefore,  regardless  of 
which  technique  was  used,  the  students 
found  the  N-fold  inspection  exercise  to  be 
a  positive  experience. 

Q2.  Did  the  exercise  help  you  better 
understand  the  course  materials? 

The  students  responded  to  this  question 
on  a  scale  of  1  (not  at  all)  to  5  (very 
much).  Figure  2  shows  that  ah  of  the  stu¬ 
dents  found  the  exercise  was  vejy  helpful  or 
a  lot  helpful. 

Qualitative  Data 

The  qualitative  feedback,  in  which  the  stu¬ 
dents  were  able  to  express  their  own  opin¬ 
ions,  provides  additional  insight  into  the 
usefulness  and  effectiveness  of  the  exer¬ 
cise.  In  this  analysis,  specific  answers  given 
for  each  question  are  listed  along  with  the 
number  of  students  who  gave  that  answer, 
shown  in  parentheses  where  i  checklist! 2 
PBR  means  that  three  students  who  used 
the  checklist  and  two  students  who  used 
PBR  gave  the  answer.  In  some  cases,  the 
response  was  given  by  only  PBR  students 
or  only  checklist  students,  e.g.,  3  PBR  in 
bullet  three  of  Q3.  This  does  not  imply 
that  the  answer  is  not  applicable  to  the 
other  technique  -  it  only  means  that  no 
students  using  the  other  technique  provid¬ 
ed  an  answer.  In  some  cases,  students  pro¬ 
vided  more  than  one  answer  to  each  ques¬ 
tion,  so  the  total  number  of  responses 
may  be  greater  than  12.  Q3  and  Q4  from 
the  post-study  survey  were  geared  towards 
addressing  Educational  Goals  2  and  3.  Q5 


Figure  2:  Understanding  the  Course  Materials 
Results 
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Q1 .  Was  the  exercise  a  positive  or  negative  experience? 

Q2.  Did  the  exercise  help  you  better  understand  the  course  materials? 
Q3.  Did  you  see  any  benefits  from  the  exercise?  If  so  what  were  they? 
Q4.  Did  you  learn  anything  by  performing  the  exercise?  If  so,  what? 
Q5.  Did  you  see  any  drawbacks  to  the  exercise?  If  so  what  were  they? 
Q6.  How  could  the  exercise  been  improved? 


Table  1:  Survey  Questions 


and  Q6  provide  feedback  on  how  to 
improve  the  exercise. 

Q3.  Did  you  see  any  benefits  from  the 
exercise?  If  so  what  were  they? 

All  12  students  indicated  that  they  found 
some  benefit  from  participation  in  this 
exercise: 

1.  It  provided  hands-on/practical  experi¬ 
ence  (3  checklist/2  PBR). 

2.  It  helped  them  better  understand  a  real 
requirements  document  (3  checklist  / 3 
PBR). 

3.  It  helped  them  better  understand 
defect  detection  in  a  requirements 
document  (3  PBR). 

Because  the  students  obtained  hands-on 
experience  and  indicated  that  they  under¬ 
stood  a  real  requirements  document,  this 
exercise  helped  address  Educational  Goals 
2  and  3. 

Q4.  Did  you  learn  anything  by  performing 
the  exercise?  If  so,  what? 

From  this  exercise,  the  students  learned 
the  following: 

1.  The  usefulness  of  inspections  (2 
checklist/ 1  PBR). 

2.  The  difficulties  involved  in  creating 
and  using  a  real  requirements  docu¬ 
ment  (3  checklist/ 1  PBR). 

3.  The  benefits  of  using  a  method  to 
focus  a  requirements  inspection  on 
certain  aspects  of  the  requirements 
document  (2  checklist/5  PBR). 

Similar  to  Q3,  these  responses  indicate 
that  the  students  learned  the  benefits  of 
inspections,  and  the  difficulties  in  creating 
real  requirements  documents,  helping 
address  Educational  Goals  2  and  3. 

Q5.  Did  you  see  any  drawbacks  to  the 
exercise?  If  so  what  were  they? 

Only  five  (4  checklist/ 1  PBR)  of  the  12 
students  reported  any  drawbacks  of  the 
exercise: 

1 .  Not  enough  training  (3  checklist/ 1  PBR). 

2.  Not  enough  time  (2  checklist). 

On  a  positive  note,  these  drawbacks  all 
relate  to  the  logistics  of  the  exercise  and 
not  to  its  intrinsic  value.  None  of  these 
drawbacks  are  concerned  with  the  inspec¬ 


tion  procedure  that  was  used  during  the 
exercise. 

Q6.  How  could  the  exercise  have  been 
improved? 

1.  Expand  the  exercise  (1  checklist/ 1 
PBR). 

2.  Provide  more  domain  knowledge  (2 
checklist). 

3.  Allow  more  time  for  various  activities 
(2  checldist/2  PBR). 

4.  Provide  more  training  (1  checklist/4 
PBR). 

These  suggestions  generally  relate  to  the 
drawbacks  cited  in  Q5.  It  was  interesting 
that  two  students  asked  for  a  more  exten¬ 
sive  exercise  that  allowed  them  to  obtain 
more  practice  and  experience  using  the 
inspection  techniques.  This  request  sug¬ 
gests  that  the  students  believed  that  even 
more  benefit  would  be  obtained  by 
expanding  the  scope  of  the  exercise. 

Summary  and  Conclusion 

This  article  describes  the  use  of  a  require¬ 
ments  validation  exercise  in  a  graduate- 
level  RE  course.  In  the  exercise,  the  stu¬ 
dents  validated  a  software  requirements 
document  using  a  meeting-based  N-fold 
inspection.  The  students  provided  their 
opinions  and  feedback  about  the  useful¬ 
ness  of  the  exercise  in  a  post-exercise  sur¬ 
vey.  These  results  showed  that  the  exercise 
achieved  its  goals. 

Overall,  students  were  highly  satisfied 
with  the  exercise  content  and  found  it  to 
be  helpful.  The  exercise  helped  students 
understand  what  a  software  requirements 
document  looks  like  and  gain  insight  into 
the  difficulty  and  complexity  involved  in 
its  correct  development.  They  not  only 
realized  the  importance  of  requirements 
validation  but  also  gained  hands-on  expe¬ 
rience  using  inspection  techniques.  The 
exercise  provided  the  students  with  essen¬ 
tial  knowledge  about  requirements  quality, 
enabling  them  to  better  understand  other 
course  material  such  as  the  following:  elic¬ 
itation,  analysis,  and  specification. 
Moreover,  though  not  empirically  evaluat¬ 
ed,  the  team  meetings  in  this  exercise  gave 
the  students  an  opportunity  to  practice 


their  communication  and  teamwork  skills, 
which  are  essential  for  their  future  careers. 

Based  on  the  feedback  provided  by  the 
students,  the  following  modifications  are 
being  considered  for  future  similar  class 
exercises: 

1.  Provide  more  training  on  the  inspec¬ 
tion  techniques  by  using  case  studies. 

2.  Give  specific  instructions  on  the  struc¬ 
ture  and  organization  of  the  team 
meeting. 

3.  Extend  the  length  of  the  exercise  to 
allow  additional  time  for  training  and 
the  individual  inspection. 

4.  To  make  the  exercise  more  realistic, 
stakeholders  of  the  software  require¬ 
ments  document  will  be  invited  to 
class,  and  help  students  to  obtain  more 
domain  knowledge. 

5.  When  the  N-fold  inspection  is  fin¬ 
ished,  the  defect  lists  will  be  given  to 
the  owner  of  the  requirements  docu¬ 
ment  to  understand  the  disposition  of 
those  defects. 

This  study  was  performed  in  a  gradu¬ 
ate-level  university  course;  therefore,  the 
next  step  is  to  perform  additional  valida¬ 
tion  in  an  industrial  setting.  Furthermore, 
the  positive  experience  with  the  N-fold 
inspection  process  during  RE  suggests 
that  it  may  have  applicability  in  other  phas¬ 
es  of  the  software  life  cycle.  In  the  future, 
we  will  seek  out  opportunities  to  replicate 
these  experiences  in  other  aspects  of  the 
software  engineering  curriculum. ♦ 
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Integrating  Software  Assurance  Knowledge  Into 
Conventional  Curricula 


Dr.  Nancy  R.  Mead  Dr.  Dan  Shoemaker  Jeffrey  A.  Ingalsbe 

Software  Engineering  Institute  Universif  of  Detroit  Mercjj  Ford  Motor  Co. 

One  of  our  challenges  is  deciding  how  best  to  address  software  assurance  in  university  curricula.  One  approach  is  to  incorpo¬ 
rate  software  assurance  knowledge  areas  into  conventional  computing  curricula.  In  this  article,  we  discuss  the  results  of  a  com¬ 
parison  of  the  Common  Body  of  Knowledge  (CBK)  for  Secure  Software  Assurance  with  traditional  computing  disciplines. 

The  comparison  indicates  that  software  engineering  is  probably  the  best  fit  for  such  knowledge  areas,  although  there  is  overlap 
with  other  computing  curricula  as  well 


Defects  are  not  an  option  in  today’s 
world.  Much  of  our  national  well¬ 
being  depends  on  software.  So  the  one 
thing  that  America’s  citizens  should  be  able 
to  expect  is  that  that  software  will  be  free 
of  bugs.  Sadly,  that  is  not  the  case.  Instead, 
commonly  used  software  engineering  practices  per¬ 
mit  dangerous  defects  that  let  attackers  compromise 
millions  of  computers  every  year .  That  happens 
because  commercial  software  engineering  lacks  the 
rigorous  controls  needed  to  (ensure  defect  free)  prod¬ 
ucts  at  acceptable  cost  [1]. 

Most  defects  arise  from  program  or 
design  flaws,  and  they  do  not  have  to  be 
actively  exploited  to  be  considered  a  threat 
[2,  3].  In  fiscal  terms,  the  exploitation  of 
such  defects  costs  the  American  economy 
an  average  of  $60  billion  dollars  a  year  [4]. 
Worse,  it  is  estimated  that  in  the  future,  the 
nation  may  face  even  more  challengingproblems  as 
adversaries  —  both  foreign  and  domestic  —  become 
increasingly  sophisticated  in  their  ability  to  insert 
malicious  code  into  critical  software  systems  [3]. 

Given  that  situation,  the  most  impor¬ 
tant  concern  of  all  might  be  that  the 
exploitation  of  a  software  flaw  in  a  basic 
infrastructure  component  such  as  power  or 
communication  could  lead  to  a  significant 
national  disaster  [5].  The  Critical  Infra¬ 
structure  Taskforce  sums  up  the  likelihood 
of  just  such  an  event  in  the  following: 

The  nation’s  economy  is  increasing¬ 
ly  dependent  on  cyberspace.  This 
has  introduced  unknown  interde¬ 
pendencies  and  single  points  of 
failure.  A  digital  disaster  strikes 
some  enterprise  every  day,  [and] 
infrastructure  disruptions  have  cas¬ 
cading  impacts,  multiplying  their 
cyber  and  physical  effects.  [5] 

Predictions  such  as  this  are  what  moti¬ 
vated  the  National  Strategy  to  Secure 
Cyberspace,  which  mandates  the  Depart¬ 
ment  of  Homeland  Security  (DHS)  to  do 
the  following: 

...  promulgate  best  practices  and 
methodologies  that  promote 


integrity,  security,  and  reliability  in 
software  code  development,  in¬ 
cluding  processes  and  procedures 
that  diminish  the  possibilities  of 
erroneous  code,  malicious  code,  or 
trap  doors  that  could  be  intro¬ 
duced  during  development.  [5] 

Given  the  scope  of  that  directive,  one 
obvious  solution  is  to  ensure  that  secure 
software  practices  are  embedded  in  work¬ 
force  education,  training,  and  develop¬ 
ment  programs  nationwide.  The  problem 
is  that  there  is  currently  no  authoritative 
point  of  reference  to  define  what  should 
be  taught  [3].  For  that  reason,  in  2005 
DHS  created  a  working  group  to  define  a 
CBK  for  Secure  Software  Assurance 
<https:/ /buildsecurityin. us-cert.gov/ 
daisy/bsi/resources/ dhs/95.html>.  The 
goal  of  the  CBK  is  to  itemize  all  of  the 
activities  that  might  be  involved  in  pro¬ 
ducing  secure  code.  DHS  does  not  intend 
the  CBK  to  be  used  as  a  general  standard, 
directive,  or  policy  [3].  Instead,  its  sole  pur¬ 
pose  is  to  catalog  secure  practices  that 
might  be  appropriate  to  currently  existing 
academic  disciplines.  Thus,  the  CBK  is  an 
inventory  of  potential  knowledge  areas  with¬ 
in  each  contributing  discipline. 

The  CBK  assumes  the  following: 

...  software  assurance  is  not  a  sepa¬ 
rate  profession.  What  is  not  clear, 
however,  is  the  precise  relationship 
between  the  elements  of  the  CBK 
and  the  curricula  of  each  potential¬ 
ly  relevant  field.  [6] 

So,  the  challenge  is  to  correctly  inte¬ 
grate  secure  software  assurance  practices 
into  each  contributing  discipline  [3,  6] . 

Several  disciplines  could  conceivably 
benefit  from  CBK,  such  as  software  engineer¬ 
ing,  systems  engineering,  information  systems  secu¬ 
rity  engineering,  safety,  security,  testing,  informa¬ 
tion  assurance,  and  project  management  [3]. 
Consequently,  in  order  to  ensure  that  the 
right  content  is  taught  in  each,  it  is  neces¬ 
sary  to  understand  the  proper  relationship 


between  the  CBK  and  the  curricula  of 
each  relevant  discipline  [6]. 

Finding  Where  the  CBK  Fits 
Into  Current  Curricula 

The  overall  goal  of  the  CBK  is  to  ensure  ade¬ 
quate  coverage  of  requisite  knowledge  areas  in  each 
contributing  discipline  [3].  Accordingly,  the 
working  group  sought  to  understand  the 
exact  relationship  of  CBK  elements  to 
each  traditional  curriculum.  Once  that  rela¬ 
tionship  was  better  understood,  it  was  felt 
that  it  should  be  possible  to  recommend 
the  right  way  to  incorporate  CBK  content 
into  each  of  the  established  disciplines. 

That  comparison  was  materially  aided 
by  the  fact  that  the  sponsoring  societies  of 
the  three  most  influential  academic  studies 
had  just  finished  their  own  survey  of  cur¬ 
ricular  models  for  computing  curricula. 
This  was  reported  in  ‘'Computing 
Curricula  2005:  The  Overview  Report” 
commonly  called  CC2005  [7].  CC2005 
merges  the  recommendations  for  the  con¬ 
tent  and  focus  of  computer  engineering,  com¬ 
puter  science,  information  systems,  information 
technology,  and  software  engineering  curricula 
into  a  single  authoritative  summary,  which 
is  fully  endorsed  by  the  Association  for 
Computing  Machinery  (ACM),  the 
Institute  of  Electrical  and  Electronics 
Engineers  (IEEE)  Computer  Society,  and 
the  Association  for  Information  Systems. 

CC2005  specifies  40  topic  areas.  These 
40  topics  represent  the  entire  range  of 
subject  matter  for  all  five  major  comput¬ 
ing  disciplines.  The  report  specifically 
states  the  following: 

Each  one  of  the  five  discipline- 
specific  curricula  represents  the 
best  judgment  of  the  relevant  pro¬ 
fessional,  scientific,  and  education¬ 
al  associations  and  serves  as  a  defi¬ 
nition  of  what  these  degree  pro¬ 
grams  should  be  and  do.  [7] 

In  addition  to  the  40  topic  areas,  which 
in  effect  capture  all  of  the  knowledge 
requirements  for  computing  curricula 
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Knowledge  Areas  All  Disciplines 

Cites 

Knowledge  Areas  All 
Disciplines 

Cites 

Integrative  Programming 
(integrated) 

9 

Analysis  of  Requirements 

1 

Algorithms 

1 

Technical  Requirements 
Analysis 

274 

Complexity 

6 

Engineering  Economics  for 
Software 

1 

Architecture 

150 

Software  Modeling  and 
Analysis 

2 

Operating  Systems  Principles  and 
Design 

5 

Software  Design 

255 

Operating  Systems  Configuration 
and  Use 

5 

Software  V&V 

401 

Platform  Technologies 

3 

Software  Evolution 
(Maintenance) 

438 

Theory  of  Programming  Languages 

10 

Software  Process 

296 

Human-Computer  Interaction  (HCI) 

5 

Software  Quality 

163 

Graphics  and  Visualization 

1 

Information  Management  (DB) 
Practice 

1 

Non-Computing  Topics 

Cites 

Legal/Professional/Ethics/Society 

93 

Risk  Management 

86 

Information  Systems  Development 

7 

Project  Management 

156 

Table  1 :  Degree  to  Which  CC  2005  Knowledge  Areas  Are  Reflected  in  the  CBK 


along  with  a  ranking  of  their  relative 
emphasis  in  each  specific  discipline, 
CC2005  also  summari^^es  the  expectations  for 
the  student  after  graduation  [7] .  This  summary 
identifies  60  competencies  that  should  be 
expected  for  each  graduate.  By  referencing 
those  identified  competency  outcomes,  it 
is  relatively  easy  to  see  the  relationship 
between  CBK  knowledge  elements  and 
the  CC2005  curricular  requirements.  It  is 
also  easier  to  see  the  places  where  there  is 
a  misalignment  between  the  CBK  and 
each  discipline’s  curricular  goals. 

The  CBK  was  mapped  to  the  CC2005 
recommendations  for  only  three  of  the 
five  disciplines.  The  two  disciplines  at 
opposite  ends  of  the  CC2005  continuum, 
computer  engineering  and  information  technology^ 
were  omitted  because  the  former  overlaps 
too  much  with  electrical  engineering  and 
the  latter  overlaps  too  much  with  business. 

Because  these  three  curricula  (comput¬ 
er  science,  information  systems,  and  soft¬ 
ware  engineering)  have  differing  focuses, 
the  content  of  CC2005  was  examined  one 
discipline  at  a  time.  First,  a  topic-by-topic 
analysis  of  depth  of  coverage  was  done. 
Depth  of  coverage  was  defined  as  the 
quantity  of  material  in  the  CBK  that  provides 
specific  advice  about  how  to  execute  a  given  activ¬ 
ity  in  CC2005  in  a  more  secure  fashion. 

To  obtain  a  metric,  the  assessment  of 
quantity  of  material  was  based  on  a  count  of 
the  textual  references  in  the  CBK  that 
could  be  associated  with  each  of  the  40 
topics.  The  assumption  was  that  the  more 
references  to  the  topic  in  the  CBK  the 
greater  the  importance  of  integrating 
secure  software  assurance  content  into  the 
teaching  of  that  topic  (see  Table  1  for 
degree  to  which  CC2005  Knowledge 
Areas  are  reflected  in  the  CBK). 

What  Does  This  Mean? 

The  following  eight  CC2005  topic  areas 
had  a  significant  degree  of  coverage  in  the 
CBK  (greater  than  100  references):  1) 
requirements,  2)  architecture,  3)  design,  4) 
verification  and  validation  (V&V),  5)  evo¬ 
lution  (e.g.,  maintenance),  6)  processes,  7) 
quality,  and  8)  information  systems  project 
management.  The  following  three  CC2005 
topic  areas  had  moderate  coverage  in  the 
CBK  (less  than  100  but  more  than  10):  1) 
legal/professional/ethics/ society,  2)  risk 
management,  and  3)  theory  of  program¬ 
ming  languages. 

This  mapping  shows  that  the  main 
focus  of  the  CBK  is  on  generic  software 
work  rather  than  on  the  specific  curricular 
aspects  that  characterize  the  study  itself, 
such  as  algorithms  (for  computer  science), 
or  information  systems  management  (for 
information  systems).  That  indicates  that 


CBK  content  would  be  best  integrated 
into  the  places  where  the  practical  ele¬ 
ments  of  the  life  cycle  are  introduced, 
such  as  a  software  design  project  course. 

Fit  Between  the  CBK  and 
Desired  Outcomes  for  the 
Profession 

There  were  six  priorities  in  CC2005.  These 
range  from  highest  possible  expectations 
through  highest  expectations  to  moderate  expec¬ 
tations^  low  expectations^  little  expectations^  and 
no  expectations.  One  of  the  more  interesting 
aspects  of  CC2005  is  the  60  expected  com¬ 
petencies.  Because  there  is  a  difference  in 
focus  for  each  discipline,  there  is  a  differ¬ 
ence  in  what  should  be  expected  for  each 
of  them.  For  instance,  there  is  a  different 
set  of  presumed  competencies  for  a  com¬ 
puter  scientist  than  for  a  software  engineer. 

The  60  expected  competencies  were 
taken  directly  from  the  40  learning  topics. 
Each  competency  was  examined  to  deter¬ 
mine  which  of  the  40  topics  could  be 
assigned  to  it.  For  instance,  if  the  compe¬ 
tency  was  to  design  a  user-friendly  interface, 
there  are  255  references  in  the  CBK  to 
design,  and  five  references  in  the  CBK  to 
human! computer  interfaces.  So  the  number  of 
CBK  references  for  this  outcome  was 
assigned  as  260  (Tables  2-4,  pages  18-19). 

For  computer  science  there  is  a  weak  match 
between  the  CBK  and  the  highest  possible  com¬ 
petency  expectations  in  that  only  one  of  the 
eight  outcomes  (12.5  percent)  had  any 
degree  of  coverage.  There  is  a  slightly  bet¬ 
ter  match  for  the  high  expectations  catego¬ 


ry,  three  of  10  (30  percent).  However,  there 
is  an  excellent  match  with  moderate  expec¬ 
tations,  nine  of  12  (75  percent). 

For  information  systems  there  is  a  reason¬ 
able  match  between  the  CBK  and  the  high¬ 
est  possible  competency  expectations  in  that  nine 
of  the  22  competencies  (40.9  percent) 
specified  for  that  discipline  are  covered. 
There  is  no  match  for  the  high  expecta¬ 
tions  category.  However,  there  is  a  good 
match  with  moderate  expectations,  five  of 
nine  (55.5  percent). 

For  software  engineering  there  is  a  strong 
match  between  the  CBK  and  the  highest  pos¬ 
sible  set  of  competency  expectations  in  that  four 
of  the  seven  outcomes  (57.1  percent)  are 
covered.  There  is  reasonable  match  for  the 
high  expectations  category  in  that  three  of 
12  competencies  are  covered  (25  percent). 
There  is  also  a  good  match  with  moderate 
expectations  in  that  five  of  nine  areas  are 
covered  (55.5  percent). 

Integrating  the  CBK  into  the 
World  of  Practical  Education 

One  of  the  main  inferences  that  can  be 
drawn  from  this  comparison  is  that  the  cur¬ 
rent  CBK  is  less  focused  on  theory  than  it 
is  on  application  of  the  knowledge  in  prac¬ 
tice.  In  essence,  the  results  demonstrate 
that  the  CBK  is  built  around  and  encapsu¬ 
lates  knowledge  about  practical  processes 
that  are  universally  applicable  to  securing 
software  rather  than  on  discipline- specific 
concepts,  theories,  or  activities. 

This  is  best  illustrated  by  the  matches 
themselves.  Outcomes  such  as  solve  programming 
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Computer  Science 

Highest  Possible  Expectation  (5) 

Depth  of  Coverage 

Conclusion 

Solve  programming  problems  (algorithms) 

Analysis  (274),  Design  (255) 

strong 

High  Expectation  (4) 

Depth  of  Coverage 

Conclusion 

Do  large-scale  programming  (programming) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Develop  new  software  systems  (programming) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Create  a  software  user  interface  (HCI) 

HCI  (5) 

weak 

Moderate  Expectation  (3) 

Depth  of  Coverage 

Conclusion 

Create  safety-critical  systems  (programming) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Process  (296),  V&V  (401),  PM  (156) 

Design  information  systems  (IS) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Implement  information  systems  (IS) 

Process  (296),  V&V  (401),  PM  (156) 

strong 

Maintain  and  modify  information  systems  (IS) 

Evolution  (438) 

strong 

Install/upgrade  computers  (planning) 

Process  (296),  V&V  (401),  PM  (156) 

strong 

Install/upgrade  computer  software  (planning) 

Process  (296),  V&V  (401),  PM  (156) 

strong 

Design  network  configuration  (networks) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Manage  computer  networks  (networks) 

Evolution  (438) 

strong 

Implement  mobile  computing  system  (networks) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Table  2:  Match  between  CBK  and  CC2005  Expected  Competencies  for  Computer  Science 


problems^  do  large  scale  programmings  and  design 
and  develop  new  software  andj  or  IS  are  high  pri¬ 
orities  in  all  of  the  disciplines.  At  the  same  time, 
each  of  these  also  has  a  significant  degree 
of  coverage  in  the  CBK. 

High-priority  items  in  each  of  these  dis¬ 
ciplines  that  were  not  good  matches  with 


the  CBK  tended  to  be  such  competencies 
as  prove  theoretical  results  (computer  science), 
develop  proof  of-concept programs  (computer  sci¬ 
ence),  select  database  products  (information 
systems),  use  spreadsheet  features  well  (informa¬ 
tion  systems),  do  small  scale  programming  (soft¬ 
ware  engineering),  and  produce  graphics  or 


game  software  (software  engineering). 

Others,  such  as  create  a  software  user  inter¬ 
face,  were  a  mixed  bag,  with  a  good  match 
to  design  but  a  poor  match  to  HCI. 

So,  while  these  competencies  might  be 
individually  important  to  their  specific  disci¬ 
plines,  they  are  not  essential  elements  of 


Table  3:  Match  Between  CBK  and  CC2005  Expected  Competencies  for  Information  Systems 


Information  Systems/Information  Technology 

Highest  Possible  Expectation  (5) 

Depth  of  Coverage 

Conclusion 

Create  a  software  user  interface  (IS) 

HCI  (5) 

weak 

Define  information  system  requirements  (IS) 

IS  Dev.  (7),  Bus.  Req.  (1),  Analysis  (274) 

strong 

Design  information  systems  (IS) 

Design  (255),  Modeling  (5),  Architecture  (150) 

strong 

Maintain  and  modify  information  systems  (IS) 

Evolution  (438) 

strong 

Model  and  design  a  database  (DB) 

DB  (1),  Design  (255) 

strong 

Manage  databases  (DB) 

Evolution  (438) 

strong 

Develop  corporate  information  plan  (planning) 

Process  (296) 

strong 

Develop  computer  resource  plan  (planning) 

PM  (156) 

strong 

Schedule/budget  resource  upgrades  (planning) 

PM  (156) 

strong 

Develop  business  solutions  (integration) 

Bus.  Req  (1),  Modeling  (5),  Design  (255) 

strong 

High  Expectation  (4) 

Depth  of  Coverage 

Conclusion 

None 

n/a 

Moderate  Expectation  (3) 

Depth  of  Coverage 

Conclusion 

Develop  new  software  systems  (programming) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Install/upgrade  computer  software  (planning) 

PM  (155) 

strong 

Manage  computer  networks  (networks) 

Evolution  (238) 

strong 

Manage  communication  resources  (networks) 

PM  (155),  Economics  (1) 

strong 
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Software  Engineering 

Highest  Possible  Expectation  (5) 

Depth  of  Coverage 

Conclusion 

Do  large-scale  programming  (programming) 

Analysis  (274),  Design  (255),  Architecture  150) 

strong 

Develop  new  software  systems  (programming) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Create  safety-critical  systems  (programming) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Process  (296),  V&V  (401),  PM  (156) 

strong 

Manage  safety-critical  projects  (programming) 

V&V  (401),  PM  (156),  Evolution  (438) 

strong 

High  Expectation  (4) 

Depth  of  Coverage 

Conclusion 

Develop  new  software  systems  (programming) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Create  a  software  user  interface  (HCI) 

HCI  (5) 

weak 

Define  information  system  requirements  (IS) 

IS  Development  (7),  Bus.  Req.  (1),  Analysis  (274) 

strong 

Moderate  Expectation  (3) 

Depth  of  Coverage 

Conclusion 

Design  a  human-friendly  device  (HCI) 

HCI  (5),  Design  (255) 

strong 

Design  information  systems  (IS) 

Design  (255),  Modeling  (5),  Architecture  (150) 

strong 

Maintain  and  modify  information  systems  (IS) 

Evolution  (438) 

strong 

Install/upgrade  computers  (planning) 

Process  (296),  V&V  (401),  PM  (156) 

strong 

Install/upgrade  computer  software  (planning) 

Process  (296),  V&V  (401),  PM  (156) 

strong 

Manage  computer  networks  (networks) 

Evolution  (438) 

strong 

Implement  mobile  computing  system  (networks) 

Analysis  (274),  Design  (255),  Architecture  (150) 

strong 

Table  4:  Match  between  CBK  and  CC2005  Expected  Competencies  for  Software  Engineering 


secure  software  assurance  as  defined  by  the 
CBK.  In  view  of  that  finding,  it  would 
appear  to  be  easier  to  introduce  CBK  con¬ 
tent  into  curricula  that  is  focused  on  teach¬ 
ing  pragmatic  software  processes  and  meth¬ 
ods.  And  given  its  historic  involvement  with 
those  areas,  the  discipline  of  software  engi¬ 
neering  might  be  the  place  to  start. 

Therefore,  one  additional  suggestion 
might  be  that  a  similar  study  should  be  done 
based  strictly  on  Software  Engineering 
2004,  “Curricular  Guidelines  for  Under¬ 
graduate  Programs  in  Software  Engineer¬ 
ing,”  particularly  Table  1:  Software  Engi¬ 
neering  Education  Knowledge  Elements 
[8].  That  itemizes  a  set  of  knowledge  areas  and 
knowledge  units  that  are  similar  in  focus  and 
purpose  to  the  40  knowledge  areas  con¬ 
tained  in  CC2005.  Thus,  it  should  be  possi¬ 
ble  to  better  understand  the  actual  relation¬ 
ship  between  standard  software  engineering 
curricular  content  and  the  contents  of  the 
CBK  through  that  comparison. 

There  is  another  distinct  observation 
arising  out  of  this  study.  Although  the  mod¬ 
erate  expectations  category  does  not  reflect 
priority  areas,  it  is  overwhelmingly  the  best 
aligned  category  for  each  discipline.  What 
that  might  indicate  is  that,  although  secure 
software  assurance  is  a  legitimate  area  of 
study  for  all  of  these  fields,  it  is  not  the 
highest  priority  in  any  of  them.  In  terms  of 
disciplinary  implementations,  the  practi¬ 
tioner  orientation  and  the  fact  that  security 


content  is  not  the  point  of  these  fields  indi¬ 
cates  that  courses  that  cover  practical  life- 
cycle  functions  might  be  the  place  to  intro¬ 
duce  secure  software  assurance  content 
within  any  given  discipline. 

As  a  final  note,  the  measurement 
process  used  in  this  study  (e.g.,  a  raw  count) 
is  inherently  less  accurate  than  expert  con¬ 
textual  analysis  of  the  meaning  of  each 
knowledge  element.  Therefore,  a  more  rig¬ 
orous  comparison  should  be  undertaken  to 
better  characterize  the  functional  relation¬ 
ship  between  the  items  in  the  CBK  and  the 
various  curricular  standards.  This  would  be 
particularly  justified  for  the  study  of  soft¬ 
ware  engineering  curricular  content  men¬ 
tioned  above.  Once  a  means  of  compari¬ 
son  that  everybody  can  agree  on  is  used,  it 
should  be  relatively  simple  to  work  out  the 
nuts-and-bolts  of  specific  implementations 
within  each  individual  program. ♦ 
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Software  Engineering  Continuing  Education 
at  a  Price  You  Can  Afford 


Maj  Christopher  Bohn,  Ph.D. 
yiir  Force  Institute  of  Technology 

Software  is  so  critical  to  today's  military  programs  that  failure  of  the  software  generally  results  in  failure  of  the  program. 

Hoping  for  success  is  the  surest  way  to  avoid  it.  Avoiding  software  failure  is  not  accidental;  it  requires  careful  application  of 
sound  software  engineering.  Whether  you  are  an  engineer,  a  program  manager,  a  contracting  officer,  or  anyone  else  involved  in 
the  development,  acquisition,  or  sustainment  of  a  software-intensive  system,  the  Hir  Force  Institute  of  Technology's  (AFIT) 

Software  Professional  Development  Program  (SPDP)  can  hringyou  the  education  you  need  to  achieve  software  success". 


Software  is  everywhere.  It  is  in  our  kitchen 
appliances;  it  is  in  our  cars.  It  allows  us  to 
communicate  worldwide,  and  it  helps  us 
manage  our  personnel  systems.  It  is  in  our 
weapons  systems.  Famously,  80  percent  of 
the  F-22’s  functionality  is  performed  in  soft¬ 
ware;  some  have  said  that  taking  a  picture  of 
an  F-22  is  the  only  thing  you  can  do  with  it 
that  does  not  require  software  [1].  Software 
is  so  integral  to  the  F-35  that  Lockheed 
Martin  spearheaded  the  effort  to  create  a 
safety-critical  C++  standard  [2].  There  is  no 
project  in  today’s  military  that  is  not  affect¬ 
ed  by  software.  Software,  like  any  other 
technology,  has  its  limitations;  as  dependent 
as  we  have  become  on  software,  those  limi¬ 
tations  become  our  limitations.  Many  won¬ 
der  how  we  can  add  armor  to  our  programs’ 
Achilles  heels. 

Perhaps  you  were  motivated  by 
Secretary  Wynne’s  emphasis  on  making  edu¬ 
cation  a  priority  in  your  career  [3,  4]. 
Perhaps  you  read  the  National  Defense 
Industrial  Association’s  report  on  the  top 
defense  software  engineering  issues  and  are 
wondering  how  you  can  overcome  these 
issues  in  your  program  [5].  Perhaps  you  are 
simply  looking  for  some  job-relevant  educa¬ 
tion  to  satisfy  the  Acquisition  Professional 
Development  Program  continuing  educa¬ 
tion  requirements  without  taxing  your  unit’s 
travel  budget.  We  are  here  to  help  you.  We 
can  bring  education  to  your  office  or  home, 
and  we  will  not  charge  you  or  your  organi¬ 
zation  a  dime. 

The  AFIT’s  SPDP  is  a  distance  learning, 
professional  continuing  education  program 
designed  to  benefit  the  Department  of 
Defense  (DoD)  organizations  and  individu¬ 
als  with  varying  levels  of  experience  and 
responsibility.  SPDP  is  well  into  its  second 
decade,  but  it  has  been  anything  but  stag¬ 
nant;  we  have  constantly  been  adapting  to 
meet  the  needs  of  the  defense  software 
engineering  community.  You  may  have  read 
about  SPDP  when  it  transitioned  from  a 
resident  program  to  satellite-delivered  dis¬ 
tance  learning  program  [6,  7].  You  may  have 
read  about  SPDP  when  it  transitioned  from 
satellite  delivery  to  Internet  streaming  and 


from  quarter-long  courses  to  month-long 
courses  [8].  Since  then,  we  have  been  work¬ 
ing  to  improve  the  education  we  provide  to 
our  students  [9,  10]. 

A  typical  SPDP  course  is  four  weeks 
long;  the  lectures  are  available  through 
Internet  streaming  or  they  can  be  down¬ 
loaded  to  view  offline.  This  format  has  per¬ 
mitted  our  students  to  complete  courses  in  a 
high-paced  environment;  we  have  even  had 
students  take  SPDP  courses  while  deployed 

^^Sofiwore,  like  any  other 
technology,  has  its 
limitations;  as  dependent 
as  we  have  become  on 
software,  those 
limitations  become  our 
limitations.^^ 

to  Southwest  Asia  and  while  at  sea.  SPDP 
courses  differ  from  asynchronous  Web- 
based  training  in  many  ways.  The  most  sig¬ 
nificant  is  that  they  are  instructor-led  cours¬ 
es  —  real,  human  instructors  who  provide 
the  lectures  (see  Figure  1,  page  22),  comple¬ 
mented  with  reading  assignments  from  a 
textbook.  We  also  make  use  of  online  dis¬ 
cussion  boards  and  sometimes  teleconfer¬ 
ences  to  provide  continuous  instructor- stu¬ 
dent  and  student- student  interaction. 
Finally,  our  students  are  evaluated  with 
homework  assignments  and  exams. 

Available  Courses 

We  currently  offer  12  SPDP  courses.  We 
have  two  courses  focused  on  project  man¬ 
agement: 

•  CSE  479,  Software  Project  Initiating  and 
Planning. 

•  CSE  480,  Software  Project  Monitoring 
and  Control. 

The  software  engineering  life  cycle  is  cov¬ 


ered  in  six  courses.  CSE  481,  Introduction 
to  Software  Engineering,  provides  an 

overview,  and  each  major  activity  of  the 
software  life  cycle  is  covered  in  greater  detail 
in  its  own  course: 

•  CSE  482,  Software  Requirements. 

•  CSE  483,  Software  Design. 

•  CSE  484,  Software  Implementation. 

•  CSE  485,  Software  Systems  Mainte¬ 
nance. 

•  CSE  486,  Verification,  Validation  and 
Testing. 

Our  next  three  courses  address  object-ori¬ 
ented  development: 

•  CSE  487,  Fundamentals  of  Object- 
Oriented  Systems. 

•  CSE  488,  Modeling  Object-Oriented 
Systems  using  UML. 

•  CSE  489,  Advanced  Analysis  and 
Design  of  Object-Oriented  Systems. 

Our  final  course,  CSE  496,  Software 
Engineering  Practicum,  is  a  three-week  resi¬ 
dent  course  held  at  our  campus  near  Wright- 
Patterson  AFB,  Ohio. 

With  the  exception  of  CSE  489  and 
CSE  496,  none  of  these  courses  have  pre¬ 
requisites.  You  can  choose  to  take  them  all 
or  only  the  ones  you  are  interested  in  and 
you  can  take  them  in  any  order.  We  have 
committed  to  offering  each  of  these  cours¬ 
es  at  least  once  per  year,  though  when 
demand  and  faculty  resources  are  in  accord, 
we  will  provide  more  frequent  offerings. 

As  stated  earlier,  a  typical  SPDP  course 
is  four  weeks  long.  Each  week,  the  instruc¬ 
tor  will  provide  two  lectures  and  perhaps 
will  hold  an  optional  teleconference.  There 
will  be  reading  assignments  and  homework 
assignments.  There  may  be  a  mid-term 
exam,  and  the  class  will  conclude  with  a  final 
exam. 

The  atypical  courses  are  CSE  489  and 
CSE  496,  as  these  are  project-based  courses. 
CSE  489  is  still  a  four-week,  instructor-led 
course,  but  there  is  only  one  lecture  per 
week  and  one  mandatory  teleconference  in 
which  the  students  present  project  progress. 
Enrollment  in  CSE  489  requires  completion 
of  CSE  487  and  CSE  488.  CSE  496  is  a 
three-week  resident  course  in  which  stu- 
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Figure  1:  The  author  teaches  CSE  489  while 
attending  the  2006  Systems  and  Software 
Technology  Conference. 


dents  form  a  development  team  and  have 
the  opportunity  to  apply  what  they  have 
learned;  before  enrolling  in  CSE  496,  a  stu¬ 
dent  must  have  completed  at  least  seven 
other  SPDP  courses. 

Certifications 

AFIT  offers  four  certifications  to  help  you 
mark  your  progress  through  SPDP  and  to 
help  you  demonstrate  that  you  have  taken  a 
breadth  of  courses.  The  Software  Engi¬ 
neering  Management  Certificate  is  awarded 
in  recognition  of  successful  completion  of 
topics  related  to  software  project  manage¬ 
ment  and  the  individual  components  of  the 
software  life-cycle  model;  it  will  be  awarded 
for  the  completion  of  CSE  479,  CSE  480, 
and  CSE  48  E  The  Software  Lifecycle 
Development  Certificate  is  awarded  in 
recognition  of  a  more  in-depth  study  of 
each  of  the  phases  of  the  software  life  cycle; 
it  will  be  awarded  after  the  successful  com¬ 
pletion  of  CSE  482,  CSE  483,  CSE  484,  and 
CSE  485.  The  Advanced  Software 
Development  Certificate  is  awarded  after 
the  successful  completion  of  CSE  486,  CSE 
487,  and  CSE  488,  in  recognition  of  these 
analysis,  modeling,  and  testing  topics. 
Finally,  the  Technical  Software  Develop¬ 
ment  Certificate  is  awarded  after  the  suc¬ 
cessful  completion  of  CSE  489  and  CSE 
496,  in  recognition  of  completing  the  pro¬ 
ject-centered  courses  in  the  program. 

Besides  the  AFIT  certifications,  SPDP 
can  help  you  toward  another  credential. 
AFIT’s  School  of  Systems  and  Logistics  is 
one  of  seven  registered  educational 
providers  worldwide  for  the  Institute  of 
Electrical  and  Electronics  Engineers 
(IEEE)  Computer  Society’s  Certified 
Software  Development  Professional 
(CSDP)  program  [11].  The  CSDP  certifica¬ 
tion  is  the  only  software  development  certi¬ 
fication  that  has  all  of  the  components  of  a 
professional  certification:  an  exam  demon¬ 


strating  mastery  of  the  Software 
Engineering  Body  of  Knowledge  (SWE- 
BOK),  an  experience  base,  and  continuing 
education.  While  taking  the  SPDP  courses  is 
neither  sufficient  nor  necessary  to  earn  the 
CSDP,  completing  the  curriculum  will  fully 
immerse  you  in  the  S  WEB  OK,  preparing 
you  for  the  CSDP  exam. 

Eligibility 

SPDP  classes  are  funded  through  AFIT  for 
aU  DoD  employees  (active  duty  and  reserve 
component  service  members  and  govern¬ 
ment  civilians).  Contractors  and  employees 
of  other  US.  Government  Agencies  may  also 
enroll  in  SPDP  courses  on  a  space-available 
basis.  There  is  no  tuition  charged  for  SPDP 
courses,  and  AFIT  provides  textbooks  free 
to  DoD  employees.  Contractors  and  non- 
DoD  government  employees  are  responsible 
for  procuring  their  own  textbooks  prior  to 
the  beginning  of  a  course  offering. 

Nobody  wants  to  be  another  statistic  for 
the  next  study  of  defense  software  crises. 
You  can  mitigate  this  risk  by  arming  yourself 
with  software  engineering  knowledge  and 
skills.  Fortunately,  with  the  SPDP,  you  will 
not  need  to  dig  into  your  tight  travel  funds 
and  you  will  not  need  to  figure  out  how  to 
pay  for  expensive  continuing  education 
courses.  Our  faculty  is  here  to  help.  The 
feedback  we  have  received  from  our  stu¬ 
dents  and  their  supervisors  is  that  they  usu¬ 
ally  see  improvement  during  their  current 
projects. 

If  you  are  interested  in  taking  SPDP 
courses,  or  at  least  curious,  please  visit  the 
SPDP  Web  site  at  <www.afit.edu/ls/ 
spdp/>,  e-mail  the  faculty  at  <spdp(^afit. 
edu>,  or  contact  Candace  Barker  at  (937) 
255-7777  ext.  3319,  or  DSN  785-7777  ext. 
3319.4 

Note 

1.  The  views  expressed  in  this  article  are 
those  of  the  author  and  do  not  reflect 
the  official  policy  or  position  of  the  7\ir 
Force,  DoD,  or  the  U.S.  Government. 
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The  objectives  of  this  article  are  to  examine  why  software  inspections  are  not  used  more  widely,  identify  the  issues  contribut¬ 
ing  to  their  lack  of  use,  identify  why  inspection  benefits  deteriorate  for  many  companies,  and  recommend  what  can  be  done  to 
address  and  solve  these  issues.  The  proven  benefits  of  inspections  are  too  significant  to  let  them  fall  by  the  wayside! 


For  the  purpose  of  this  article,  an  inspec¬ 
tion  is  defined  as  a  preemptive  peer 
review  of  work  products  —  by  trained  indi¬ 
viduals  using  a  well  defined  process  —  to 
detect  and  eliminate  defects  as  early  as 
possible  in  the  Software  Development 
Life  Cycle  (SDLC)  or  closest  to  the  points 
of  defect  injection. 

Background 

According  to  a  National  Institute  of 
Standards  and  Technology  (NIST)  study, 
the  problem  of  continued  delivery  of  bug-ridden 
software  is  costing  the  U.S.  economy  an  esti¬ 
mated  $59.5  billion  each  year.  The  study 
also  found  the  following: 

...although  ah  errors  cannot  be 
removed,  more  than  a  third  of 
these  costs,  or  an  estimated  $22.2 
billion,  could  be  eliminated  by  an 
improved  testing  infrastructure 
[reviews,  inspections,  etc.]  that 
enables  earlier  and  more  effective 
identification  and  removal  of  soft¬ 
ware  defects.  These  are  the  savings 
associated  with  finding  an 
increased  percentage  [but  not  100 
percent]  of  errors  closer  to  the 
development  stages  in  which  they 
were  introduced.  Currently,  over 
half  of  all  errors  are  not  found 
until  ‘downstream’  in  the  develop¬ 
ment  process  (testing)  or  during 
post-sales  software  use.  [1] 

Figure  1  shows  a  typical  relationship 
between  the  costs  of  repairing  a  defect  in 
a  given  phase  of  the  development  cycle 
versus  which  phase  the  defect  was  intro¬ 
duced.  This  relationship  gives  rise  to  the 
development  costs  described  in  the  NIST 
report. 

The  following  testimonials  answer  the 
question:  What  is  the  evidence  that  inspections 
address  the  cost  and  qualfy  issues  described  earli¬ 
er  but  are  not  widely  used  correctly  to  maximize 
defect  detection  and  removal? 

•  The  data  in  support  of  the  quality. 


cost,  and  schedule  impact  of 
inspections  is  overwhelming.  They 
are  an  indispensable  part  of  engi¬ 
neering  high-quality  software.  [3] 

Inspections  are  surely  a  key  topic, 
and  with  the  right  instrumentation 
and  training  they  are  one  of  the 
most  powerful  techniques  for 
defect  detection.  They  are  both 
effective  and  efficient,  especially 
for  up-front  activities.  In  addition 
to  large-scale  applications,  we  are 
applying  them  to  smaller  applica¬ 
tions  and  incremental  development 
(Chris  Ebert).  [3] 

Inspection  repeatedly  has  been 
demonstrated  to  yield  up  to  a  10- 
to-1  return  on  investment.  .  .  . 
depres  singly  few  practitioners 
know  about  the  30-year-old  tech¬ 
nique  of  software  inspection.  Even 
fewer  routinely  perform  effective 
inspections  or  other  types  of  peer 
reviews.  [4] 

Formal  inspections  can  raise  the 
[defect]  removal  efficiency  to  over 
95  percent.  But  part  of  the  prob¬ 
lem  here  is  that  not  a  lot  of  com¬ 
panies  know  how  to  use  these 
things.  [5] 

The  software  community  has  used 
inspections  for  almost  28  years. 
During  this  timeframe,  inspections 
have  consistently  added  value  for 
many  software  organizations.  Yet 
for  others,  inspections  never  suc¬ 
ceeded  as  well  as  expected,  primar¬ 
ily  because  these  organizations  did 
not  learn  how  to  make  inspections 
both  effective  and  low  cost.  [6] 

I  continue  to  be  amazed  at  the  num¬ 
ber  of  software  development  orga¬ 
nizations  that  do  not  use  this  pow¬ 
erful  method  [inspections]  to 
improve  quality  and  productivity.  [7] 


It  is  clear  from  these  testimonials  that 
inspections  are  the  most  effective  way  to 
improve  the  quality,  schedule,  and  cost  of 
developing  software,  but  after  all  the  years 
after  their  introduction,  why  are  they  not 
an  integral  part  of  all  software  develop¬ 
ment  life  cycles? 

The  authors  of  this  article,  Roger 
Stewart  and  Lew  Priven  each  spent  more 
than  20  years  developing  projects  that 
used  inspections  and,  for  the  past  eight 
years,  each  has  trained  a  wide  variety  of 
companies  in  the  use  of  Fagan  inspec¬ 
tions.  They  consistently  observed  that 
soon  after  inspection  training  completes, 
malicious  compliance  sets  in  by  critical  inspec¬ 
tion  execution  deviations  being  intro¬ 
duced  and/or  ineffective  shortcuts  being 
employed.  This  results  in  inspection  bene¬ 
fits  being  compromised,  leads  to  limited 
use  or  discontinuation,  and  allows  too 
many  defects  to  escape  to  later,  more  cost¬ 
ly  phases  of  test  and  customer  use. 


Back  to  Basics 

In  order  to  deal  with  the  problem  of 
inspections  not  being  widely  used  (or  not 
used  correctly  for  the  maximum  benefit), 
we  need  to  go  back  and  look  at  the  origi¬ 
nal  approach.  Inspections  were  an  out¬ 
growth  of  the  quality  message  from  gurus 
W.  Edwards  Demming  and  J.M.  Juran  to 
design  in  quality  at  the  beginning  of  the 
development  process,  instead  of  testing  in 


Figure  1 :  Cost  of  Fixing  a  Defect  [2] 
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pseudo- quality  at  the  end  of  the  produc¬ 
tion  line. 

What  naturally  followed  was  the  idea 
of  applying  sampling  quality  control  tech¬ 
niques  to  the  software  development  life 
cycle  as  if  it  were  a  production  line. 
Specifically,  this  involves  sampling  the 
product  periodically  (detect  defects),  mak¬ 
ing  adjustments  as  defects  are  found  (fix 
defects  and  improve  the  development 
process),  and  predicting  the  shipped  prod¬ 
uct  quality  based  on  the  results  of  the  sam- 

pling- 

Application  of  the  sampling  quality  con¬ 
trol  techniques  to  the  software  development 
cycle  led  to  the  development  of  the  software 
inspection  process.  The  most  widely  known 
and  practiced  inspection  process  was  intro¬ 
duced  to  the  IBM  software  community  in 
1972  by  a  team  led  by  Michael  Fagan  and 
managed  by  Lew  Priven  (co-author  of  this 
article)  [6]. 

In  the  case  of  software,  the  develop¬ 
ment  life  cycle  is  the  production  line,  and 
inspections  are  the  sampling  and  prediction 
technique.  Inspections  are  the  vehicle  to 
sample  the  product  in  the  earlier  phases  of 
the  development  life  cycle  to  detect  and  fix 
defects  closest  to  the  point  of  injection,  and 


the  data  collected  from  inspections  can  be 
used  as  the  basis  for  predicting  the  quality  of 
the  delivered  product. 

How  Have  Inspections  Evolved? 

In  1972,  Priven  published  an  IBM  Technical 
Report  which  described  a  software  develop¬ 
ment  management  system  including  points  of 
management  control  using  process  monitors 
that  evolved  into  inspections  [8].  The  man¬ 
agement  system  was  based  on  a  well-defined 
development  process  —  which  satisfied  the 
need  for  a  production  line  as  described  ear¬ 
lier.  With  the  production  line  in  place,  Priven 
hired  Michael  Fagan,  a  quality  engineer  with 
a  hardware  and  manufacturing  background, 
to  work  with  the  development  team  to  find 
a  way  to  improve  the  quality  of  delivered 
software  [6-10].  The  IBM  (Fagan) 
Inspection  Process  then  evolved  as  a  critical 
component  of  the  end-to-end  software 
development  life  cycle.  Over  the  years,  the 
integration  of  inspections  into  the  software 
development  life  cycle  has  been  lost  as  the 
inspection  process  came  to  he  viewed  as  a  standalone 
quali^  process  with  inspection  execution  becoming 
the  prime  focus.  However,  the  supporting 
infrastructure  of  a  software  development 
life  cycle  is  stiU  critical  to  successfully  imple- 


menttng  inspecUons. 

Why  Is  the  Supporting 
Development  Infrastructure 
Important? 

The  supporting  infrastructure  of  a  weU- 
defined  development  process  is  important 
because  it  requires  management  at  ah  lev¬ 
els  -  and  during  aU  development  phases  - 
to  actively  support  the  inspection  process. 
A  life-cycle  view  is  needed  because  the 
cost  and  schedule  impact  are  primarily 
borne  by  the  requirements,  design,  and 
implementation  components  of  the  orga¬ 
nization.  However,  while  these  compo¬ 
nents  also  realize  some  of  the  reduced 
cost,  higher  quality,  and  improved  sched¬ 
ule  benefits,  the  majority  of  these  benefits 
are  primarily  realized  in  testing  and  main¬ 
tenance. 

Theory  Is  Good,  but  Why  Are 
Inspections  Not  Embraced? 

In  addition  to  being  viewed  as  a  stand¬ 
alone  process,  which  lacks  a  life-cycle  view 
of  investment  and  associated  savings, 
inspections  have  also  been  characterized 
by  a  number  of  myths.  These  myths  dis¬ 
courage  implementation.  While  there  is  a 
kernel  of  truth  in  each  myth,  each  can  be 
turned  into  a  positive.  Some  examples  fol¬ 
low: 

•  Inspections  are  time  consuming. 

Yes,  they  add  up-front  development 
time  to  requirements,  design  and  code. 
However,  rather  than  being  viewed  as 
a  problem,  this  additional  up-front 
time  for  inspections  should  be  viewed 
as  an  investment  in  obtaining  the  over¬ 
all  quality,  cost,  and  schedule  benefits 
over  the  project’s  life  cycle. 

•  Inspections  are  bureaucratic  and 
one  size  fits  all.  System  engineers  and 
software  engineers,  with  support  from 
management,  need  to  have  the  flexibil¬ 
ity  to  adjust  their  inspection  process  to 
the  needs  of  the  product  under  devel¬ 
opment.  For  example,  the  difference 
between  inspecting  software  to  control 
a  jet  fighter  (where  a  defect  could  be  a 
matter  of  life  and  death)  and  software 
that  displays  a  Web  form  (where  the 
impact  of  a  defect  may  be  an  inconve¬ 
nience).  The  former  may  require  a 
broader  comprehensive  set  of  inspec¬ 
tions  while  the  latter  could  employ 
other  visual  analysis  techniques  to  sup¬ 
plement  a  base  set  of  inspections. 

•  All  work  products  must  be  inspect¬ 
ed.  There  is  a  lack  of  guidance  on 
when,  where,  and  how  to  start  an 
inspection  process.  An  approach  to 
prioritizing  what  work  products  to 


Figure  3:  A^ssessment  Methodology 
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inspect  needs  to  be  intelligently 

applied. 

While  these  are  myths  that  we  typical¬ 
ly  hear  about  inspections,  upon  further 
examination  they  are  symptoms  of  a 
much  larger  underlying  set  of  issues.  The 
remainder  of  the  article  will  focus  on  deal¬ 
ing  with  those  issues  which  we  will  later 
refer  to  as  inspection  pitfalls. 

A  Realistic  Approach 

Although  complete  inspection  coverage 
may  be  ideal,  a  realistic  approach  to  inspec¬ 
tions  is  to  formulate  a  set  of  selection  criteria 
(see  Figure  2).  These  criteria  guide  the  iden¬ 
tification  of  those  areas  of  the  product 
most  critical  to  success  or  where  problems 
are  most  likely  to  occur.  At  the  least  these 
areas  should  be  inspected.  This  addresses 
the  common  complaint  that  there  is  not 
enough  time  to  integrate  inspections  into 
tight  schedules  yet  allows  for  using  inspec¬ 
tions  for  finding  defects  where  they  are 
most  likely  to  cause  problems. 

Figure  2  addresses  this  no-time  issue  by 
showing  the  prioritization  of  what  to  inpect 
related  to  the  development  cycle  phases  of 
the  project.  There  should  be  a  strong  focus 
on  requirements  and  design,  which  are  the 
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Figure  4:  Computerised  Inpection  Tool  Overview 


most  costly  to  fix  when  discovered  later  in 
the  development  cycle  (see  Figure  1).  The 
focus  on  requirements  and  design  is  partic¬ 
ularly  important  because  our  experience  has 
shown  that  the  largest  numbers  of  defects 
are  injected  during  these  two  phases  of 
development.  One  example  from  a  TRW 
study  shows  about  52  percent  of  defects  are 


injected  in  requirements  and  28  percent  are 
injected  in  design  [11]. 

The  most  successful  implementations 
of  inspections  have  been  in  organizations 
that  have  multi-level  active  management 
support  of  inspections  and  a  well-defined 
development  life  cycle  with  pre-existing 
emphasis  on  planning,  monitoring,  and 


Table  1 :  Tasks  Associated  With  Inpection  Pitfalls 


No. 

Pitfall 

Pitfall  Risks 

Pitfall  Solutions 

1 

Lack  of  supportive 

SDLC  infrastructure 

•  Immature  practices  for  planning,  data 
collection,  reporting,  monitoring,  and  tracking 

•  Leads  to  Pitfalls  #3,  4,  6,  10 

•  Assessment  methodology 
°  Step  1 :  Assess  client  SDLC 
°  Step  2:  Recommend  any  changes 

2 

Poor  management  understanding 
of  the  Inspection  Process,  its 
benefits,  and  their  responsibilities 

•  Leads  to  Pitfalls  #4,  6,  8,  9 
°  Inadequate  inspection:  schedules,  tools 
facilitation,  implementation 

•  Upper  management  overview 

•  Management  performance  class 

•  Student  feedback  from  inspection  class 

3 

No  computerized 
management-planning  tools 

•  Inadequate  schedule  time  (Pitfall  #4) 

•  No  savings  appreciation,  leads  to  no 
inspections  or  too  few  inspections 

•  Planning  counter  tool 

•  Savings/cost-estimator  tool 

4 

Too  little  schedule  time 
for  inspections 

•  Defects  escape  to  more  costly  phases  to  fix 

•  Inspections  not  correctly  executed 

•  Leads  to  malicious  compliance 

•  Inspection  planning  counter  tool 

•  Management  performance  class 

•  Criteria  for  prioritizing  what  to  inspect 

5 

No  computerized  inspector  tools 

•  Inconsistency,  compromising  shortcuts 

•  Defects,  escape  to  more  costly  phases  to  fix 

•  Preparation  tool 

•  Inspection  meeting  tool 

•  Data  analysis  tool,  team  analysis  tool 

6 

Inadequate  monitoring  of 
inspection  execution  and 
tracking  of  results 

•  Inspection  process  execution  deteriorates 

•  Defects  escape  to  more  costly  phases  to  fix 

•  Employees  lose  interest  when  savings 
summaries  are  not  periodically  shared 

•  ROI  calculators  for  text  and  code 

•  Data  analysis  tool,  team  analysis  tool 

•  Aggregate  results  calculator  tool 

7 

No  post-class 
practitioner  refresher 

•  Process  misunderstood,  compromising 
shortcuts  introduced,  defects  escape 

•  Seminar  for  previous  students 

•  Inspection  role- reference  card 

•  Inspection  product  checklist  kit 

8 

No  inspection  facilitator/ 
project  champion 

•  Inspection  process  issues  not  addressed, 
coordinated,  or  resolution  disseminated 

•  Inconsistent  or  incorrect  inspection  execution 

•  Little  useful  feedback  to  management 

•  Upper  management  overview 

•  Management  performance  class 

9 

Slow  inspection  implementation 
by  project  teams 

•  Ineffective  start  or  no-start  occurs 

•  Inspection  training  forgotten;  incorrect 
execution 

•  Inspector  training  accommodating 
multiple  classes,  of  2  days  or  less, 
per  week 

10 

No  inspection  process  capture 

•  Process  misunderstood,  inconsistent 
execution,  defects  escape 

•  No  repository  for  project  lessons  learned 

•  Course  material  tailoring 

•  Inspection  process  capture  tool 
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Road  Map  to  Successful  Inspection  Implementation 


Figure  5:  Inspection  Infrastructure 
measurements  use. 

Development  Infrastructure 
to  Support  Inspections 

There  is  a  lot  of  guidance  on  the  structure 
of  inspections  such  as  the  Institute  for 
Electronics  and  Electrical  Engineers 
(IEEE)  Standard  1028-1997  [12]  and  how 
to  conduct  an  inspection,  but  little  guid¬ 
ance  on  the  following: 

1.  How  to  select  what  to  inspect  (see 
Figure  2). 

2.  How  to  develop  an  appropriate  soft¬ 
ware  development  life-cycle  infrastruc¬ 
ture  that  provides  the  necessary  frame¬ 
work  for  successful  implementation  of 
inspections. 

3.  How  to  determine  what  computerized 
tools  are  needed  to  ensure  proper 
inspection  execution  and  management 
visibility  into  results,  project  savings, 
and  return  on  investment  (ROI).  For 
example,  because  of  the  lack  of 
inspection  tools,  data  collection  - 
which  is  too  often  left  to  the  discretion 
of  the  inspection  teams  —  is  often  not 
performed  or  is  performed  inconsis¬ 
tently.  Therefore,  data  needed  to  eval¬ 
uate  inspection  effectiveness  is  not 
easily  available  to  management. 

These  three  items  will  be  discussed 

further  in  the  next  section. 

Successful  inspection  implementation 
requires  a  software  development  life-cycle 
infrastructure  that  demands  planning,  data 
collection,  reporting,  monitoring,  and 
tracking.  Introducing  inspections  into  a 

®  CMMI  is  registered  in  the  U.S.  Patent  and  Trademark 
Office  by  Carnegie  Mellon  University. 


project  culture  that  does  not  believe  in  and 
have  a  development  infrastructure  that 
actively  supports  these  activities  is  fraught 
with  risk. 

Developing  an  appropriate  infrastruc¬ 
ture  begins  with  selecting  a  framework 
upon  which  to  build  your  development 
life  cycle.  A  widely  accepted  framework  is 
the  Capability  Maturity  Model®  (CMM®), 
and  its  successor  CMM-Integration 
(CMMI®).  However,  as  Watts  Humphrey 
points  out  in  [13],  ‘Although  the  CMM 
[and  CMMI]  provides  a  powerful 
improvement  framework,  its  focus  is  nec¬ 
essarily  on  what  organizations  should  do  - 
not  how  they  should  do  it.” 

There  are  four  key  steps  to  filling  out 
the  development  framework: 

1.  Select  a  development  model  (e.g.,  iter¬ 
ative,  incremental,  waterfall,  spiral, 
agile). 

2.  Clearly  define  the  development  life 
cycle  by  identifying  and  recording  for 
each  process  within  the  life  cycle,  its 
required  inputs,  the  input’s  entrance 
criteria,  the  what  and  how  of  the 
process,  the  expected  outputs,  and  the 
output’s  exit  criteria. 

3.  Get  process  agreement  by  all  compo¬ 
nents  of  the  development  organization 
(e.g.,  requirements  generators,  design¬ 
ers,  coding/implementers,  testers,  etc.). 

4.  Determine  which  project  tools  will  be 
used  for  planning,  data  collection, 
reporting,  monitoring,  and  tracking 
(tool  examples  are  critical  path,  earned 
value,  etc.). 

When  these  steps  are  completed,  the 
introduction  of  inspections  has  the  neces¬ 


sary  framework  (i.e.,  development  infra¬ 
structure)  for  ongoing  success  and  for 
inspections  to  be  accepted  as  a  very  inte¬ 
gral  part  of  the  end-to-end  development 
life-cycle. 

How  an  Inspection  Methodology 
Can  Reinvigorate  Inspections 

Inspections  will  only  be  successful  long 
term  if  they  are  integral  to  a  well-defined 
development  process  that  has  active  man¬ 
agement  support  in  each  phase  of  devel¬ 
opment.  The  methodology  shown  in 
Figure  3  (see  page  25)  starts  with  an 
assessment  to  ensure  an  adequate  devel¬ 
opment  life-cycle  infrastructure  is  in  place 
prior  to  inspection  training.  Steps  1  and  2 
in  Figure  3  are  the  assessment  steps. 

Once  the  development  infrastructure 
is  in  place,  what  else  needs  to  be  done? 
Based  on  our  experience  in  training  more 
than  5,000  inspectors  in  companies  at 
more  than  50  locations,  evaluating  the  data 
collected  and  observing  the  ongoing 
implementation  or  lack  thereof,  we  have 
identified  10  inspection  pitfalls,  each  of 
which  inhibits  inspection  implementation. 
These  inspection  pitfalls  must  be  resolved 
to  achieve  lasting  benefits  from  inspec¬ 
tions. 

The  10  inspection  pitfalls  and  associat¬ 
ed  risks  are  shown  in  Table  1  (see  page 
25).  Note:  The  lack  of  a  well-defined 
SDLC  infrastructure,  discussed  earlier,  is 
the  first  pitfall. 

Table  1  identifies  how  each  inspection 
pitfall  leads  to  findable  defects  not  being 
discovered  with  inspections,  resulting  in 
the  following: 

A.  Development  cost  savings  are  not  fully 
realized. 

B.  Quality  improvements  are  not  fully 
achieved. 

C.  Maintenance  and  support  savings  are 
not  realized. 

D.  Inspections  could  become  a  total  cost, 
not  a  savings. 

We  distinguish  between  the  develop¬ 
ment  life-cycle  infrastructure  —  within 
which  inspections  fit  (previous  section), 
and  the  inspection  infrastructure  -  which 
enables  proper  inspection  execution  for 
achieving  the  maximum  benefit.  An 
enabling  inspection  infrastructure  must 
address  all  10  pitfalls  and  would  consist  of 
the  following: 

1.  Computerized  management  tools  for 
use  in  planning  inspections  and  pre¬ 
dicting  the  overall  project  costs  and 
savings  from  applying  inspections  (see 
Figure  4  on  page  25  for  an  inspection 
tool  overview  example). 

2.  Computerized  tools  to  aid  inspectors 
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in  correctly  and  consistently  perform¬ 
ing  inspections,  gathering  inspection 
related  data,  and  performing  analysis 
to  identify  how  future  inspections  can 
be  improved. 

3.  Monitoring  and  analysis  computerized 
tools  for  management’s  post-inspec¬ 
tion  evaluation  of  individual  inspec¬ 
tions. 

4.  Computerized  management  tools  for 
analyzing  inspection  ROI  and  an 
aggregate  calculator  for  assessing  and 
tracking  the  resulting  project  savings 
from  multiple  inspections. 

5.  An  inspection  process  that  provides 
flexibility  for  prioritizing  what  to 
inspect  as  shown  in  Figure  2. 

6.  Ability  to  have  customized  training 
material  which  incorporates  your  ter¬ 
minology  and  is  based  on  your  needs. 

7.  Rapid  training  (two  days  or  less)  of 
project  personnel  in  a  comprehensive 
training  course  with  significant  focus 
on  requirements  and  design. 

8.  An  overview  briefing  for  upper  man¬ 
agement  along  with  a  more  rigorous 
management  performance  course  so 
upper  managers  and  project  leaders 
can  fully  understand  the  inspection 
process,  its  benefits,  and  their  respon¬ 
sibilities 

9.  Follow-up  practitioner  refreshers  to 
deal  with  any  implementation  prob¬ 
lems  —  focused  on  making  inspection 
implementation  successful  both  initial¬ 
ly  and  long-term. 

10.  An  inspection  process  capture  tool  to 
enable  inspections  to  quickly  become 
an  integral  part  of  a  company’s  SDLC 
infrastructure. 

Table  1  shows  how  an  Inspection 
Methodology  can  solve  and  prevent  the  10 
inspection  pitfalls. 

The  Road  Map  to  Success 

The  pitfall  solution  road  map  in  Figure  5 
shows  the  solution  relationships  that  pro¬ 
vide  for  successful  software  inspection 
implementation  that  will  endure  over  the 
long  term.  The  pitfall  solutions  provide 
the  inspection  infrastructure  that,  together 
with  a  comprehensive  inspector  training 
program,  forms  an  inspection  methodolo¬ 
gy  for  achieving  a  lasting  and  successful 
inspection  program. 

Summary 

Our  experience  has  shown  us  that  inspec¬ 
tions  can  live  up  to  their  potential  and  be 
embraced  by  the  development  community 
if  the  following  happens: 

•  Inspections  are  integral  to  a  well- 
defined  software  development  life- 
cycle  infrastructure  supported  by  man¬ 


agement  in  each  phase  of  develop¬ 
ment. 

•  Inspections  are  flexible  in  determining 
what  to  inspect. 

•  Computerized  tools  are  available  to 
assist  management  in  planning  inspec¬ 
tions  and  estimating  project  savings 
before  commitment. 

•  Computerized  tools  are  available  to 
guide  the  inspection  teams. 

•  Management  tools  are  available  for 
monitoring  inspection  process  confor¬ 
mance  (not  an  individual’s  perfor¬ 
mance)  and  tracking  resulting  inspec¬ 
tion  benefits. 

•  Project  personnel  are  provided  with 
the  proper  training  and  follow-up  sup- 
port.^ 
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Where  Are  the  Software  Engineers  of  Tomorrow? 
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It  is  our  view  that  Computer  Science  (CS)  education  is  neglecting  basic  skills,  in  particular  in  the  areas  of  programming  and 
formal  methods.  We  consider  that  the  general  adoption  of  Java  as  a  first  programming  language  is  in  part  responsible  for  this 
decline.  We  examine  briefly  the  set  of  programming  skills  that  should  be  part  of  every  software  professionals  repertoire. 


It  is  all  about  programming!  Over  the  last 
few  years  we  have  noticed  worrisome 
trends  in  CS  education.  The  following  rep¬ 
resents  a  summary  of  those  trends: 

1.  Mathematics  requirements  in  CS  pro¬ 
grams  are  shrinking. 

2.  The  development  of  programming 
skills  in  several  languages  is  giving  way 
to  cookbook  approaches  using  large 
libraries  and  special-purpose  packages. 

3.  The  resulting  set  of  skills  is  insufficient 
for  today’s  software  industry  (in  partic¬ 
ular  for  safety  and  security  purposes) 
and,  unfortunately,  matches  well  what 
the  outsourcing  industry  can  offer.  We 
are  training  easily  replaceable  profes¬ 
sionals. 

These  trends  are  visible  in  the  latest 
curriculum  recommendations  from  the 
Association  for  Computing  Machinery 
(ACM).  Curriculum  2005  does  not  mention 
mathematical  prerequisites  at  all,  and  it 
mentions  only  one  course  in  the  theory  of 
programming  languages  [1] . 

We  have  seen  these  developments  from 
both  sides:  As  faculty  members  at  New 
York  University  for  decades,  we  have 
regretted  the  introduction  of  Java  as  a  first 
language  of  instruction  for  most  computer 
science  majors.  We  have  seen  how  this 
choice  has  weakened  the  formation  of  our 
students,  as  reflected  in  their  performance 
in  systems  and  architecture  courses.  As 
founders  of  a  company  that  specializes  in 
Ada  programming  tools  for  mission-critical 
systems,  we  find  it  harder  to  recruit  quali¬ 
fied  applicants  who  have  the  right  founda¬ 
tional  skills.  We  want  to  advocate  a  more 
rigorous  formation,  in  which  formal  meth¬ 
ods  are  introduced  early  on,  and  program¬ 
ming  languages  play  a  central  role  in  CS 
education. 

Formal  Methods  and  Software 
Construction 

Formal  techniques  for  proving  the  correct¬ 
ness  of  programs  were  an  extremely  active 
subject  of  research  20  years  ago.  However, 


the  methods  (and  the  hardware)  of  the 
time  prevented  these  techniques  from 
becoming  widespread,  and  as  a  result  they 
are  more  or  less  ignored  by  most  CS  pro¬ 
grams.  This  is  unfortunate  because  the 
techniques  have  evolved  to  the  point  that 
they  can  be  used  in  large-scale  systems  and 
can  contribute  substantially  to  the  reliabili¬ 
ty  of  these  systems.  A  case  in  point  is  the 
use  of  SPARK  in  the  re-engineering  of  the 
ground-based  air  traffic  control  system  in 
the  United  Kingdom  (see  a  description  of 
iFACTS  -  Interim  Future  Area  Control 
Tools  Support,  at  <www.nats.co.uk/ arti- 
cle/90>).  SPARK  is  a  subset  of  Ada  aug¬ 
mented  with  assertions  that  allow  the 
designer  to  prove  important  properties  of 
a  program:  termination,  absence  of  run¬ 
time  exceptions,  finite  memory  usage,  etc. 
[2].  It  is  obvious  that  this  kind  of  design 
and  analysis  methodology  (dubbed 
Correctness  by  Construction)  will  add  sub¬ 
stantially  to  the  reliability  of  a  system 
whose  design  has  involved  SPARK  from 
the  beginning.  However,  PRAXIS,  the 
company  that  developed  SPARK  and 
which  is  designing  iFACTS,  finds  it  hard  to 
recruit  people  with  the  required  mathemat¬ 
ical  competence  (and  this  is  present  even  in 
the  United  Kingdom,  where  formal  meth¬ 
ods  are  more  widely  taught  and  used  than 
in  the  United  States). 

Another  formal  approach  to  which  CS 
students  need  exposure  is  model  checking 
and  linear  temporal  logic  for  the  design  of 
concurrent  systems.  For  a  modern  discus¬ 
sion  of  the  topic,  which  is  central  to  mis¬ 
sion-critical  software,  see  [3]. 

Another  area  of  computer  science 
which  we  find  neglected  is  the  study  of 
floating-point  computations.  At  New  York 
University,  a  course  in  numerical  methods 
and  floating-point  computing  used  to  be 
required,  but  this  requirement  was  dropped 
many  years  ago,  and  now  very  few  students 
take  this  course.  The  topic  is  vital  to  all  sci¬ 
entific  and  engineering  software  and  is 
semantically  delicate.  One  would  imagine 
that  it  would  be  a  required  part  of  all  cours¬ 
es  in  scientific  computing,  but  these  often 


take  MatLab  to  be  the  universal  program¬ 
ming  tool  and  ignore  the  topic  altogether. 

The  Pitfalls  of  Java  as  a  First 
Programming  Language 

Because  of  its  popularity  in  the  context  of 
Web  applications  and  the  ease  with  which 
beginners  can  produce  graphical  programs, 
Java  has  become  the  most  widely  used  lan¬ 
guage  in  introductory  programming  cours¬ 
es.  We  consider  this  to  be  a  misguided 
attempt  to  make  programming  more  fun, 
perhaps  in  reaction  to  the  drop  in  CS 
enrollments  that  followed  the  dot-com 
bust.  What  we  observed  at  New  York 
University  is  that  the  Java  programming 
courses  did  not  prepare  our  students  for 
the  first  course  in  systems,  much  less  for 
more  advanced  ones.  Students  found  it 
hard  to  write  programs  that  did  not  have  a 
graphic  interface,  had  no  feeling  for  the 
relationship  between  the  source  program 
and  what  the  hardware  would  actually  do, 
and  (most  damaging)  did  not  understand 
the  semantics  of  pointers  at  all,  which 
made  the  use  of  C  in  systems  program¬ 
ming  very  challenging. 

Let  us  propose  the  following  principle: 
The  irresistible  beauty  of  programming 
consists  in  the  reduction  of  complex  for¬ 
mal  processes  to  a  very  small  set  of  primi¬ 
tive  operations.  Java,  instead  of  exposing 
this  beauty,  encourages  the  programmer  to 
approach  problem-solving  kke  a  plumber 
in  a  hardware  store:  by  rummaging  through 
a  multitude  of  drawers  (i.e.  packages)  we 
will  end  up  finding  some  gadget  (i.e.  class) 
that  does  roughly  what  we  want.  How  it 
does  it  is  not  interesting!  The  result  is  a  stu¬ 
dent  who  knows  how  to  put  a  simple  pro¬ 
gram  together,  but  does  not  know  how  to 
program.  A  further  pitfall  of  the  early  use 
of  Java  libraries  and  frameworks  is  that  it  is 
impossible  for  the  student  to  develop  a 
sense  of  the  run-time  cost  of  what  is  writ¬ 
ten  because  it  is  extremely  hard  to  know 
what  any  method  call  will  eventually  exe¬ 
cute.  A  lucid  analysis  of  the  problem  is  pre¬ 
sented  in  [4]. 

We  are  seeing  some  backlash  to  this 
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approach.  For  example,  Bjarne  Stroustrup 
reports  from  Texas  A  &  M  University  that 
the  industry  is  showing  increasing  unhappi¬ 
ness  with  the  results  of  this  approach. 
Specifically,  he  notes  the  following: 

I  have  had  a  lot  of  complaints  about 
that  [the  use  of  Java  as  a  first  pro¬ 
gramming  language]  from  industry, 
specifically  from  AT&T,  IBM,  Intel, 
Bloomberg,  NI,  Microsoft,  Lock- 
heed-Martin,  and  more.  [5] 

He  noted  in  a  private  discussion  on  this 
topic,  reporting  the  following: 

It  [Texas  A&M]  did  [teach  Java  as 
the  first  language].  Then  I  started 
teaching  C++  to  the  electrical  engi¬ 
neers  and  when  the  EE  students 
started  to  out-program  the  CS  stu¬ 
dents,  the  CS  department  switched 
to  C++.  [5] 

It  will  be  interesting  to  see  how  many 
departments  follow  this  trend.  At 
AdaCore,  we  are  certainly  aware  of  many 
universities  that  have  adopted  Ada  as  a  first 
language  because  of  similar  concerns. 

A  Real  Programmer  Can 
Write  in  Any  Language  (C, 
Java,  Lisp,  Ada) 

Software  professionals  of  a  certain  age  will 
remember  the  slogan  of  old-timers  from 
two  generations  ago  when  structured  pro¬ 
gramming  became  the  rage:  Real  program¬ 
mers  can  write  Fortran  in  any  language. 
The  slogan  is  a  reminder  of  how  thinking 
habits  of  programmers  are  influenced  by 
the  first  language  they  learn  and  how  hard 
it  is  to  shake  these  habits  if  you  do  all  your 
programming  in  a  single  language. 
Conversely,  we  want  to  say  that  a  compe¬ 
tent  programmer  is  comfortable  with  a 
number  of  different  languages  and  that  the 
programmer  must  be  able  to  use  the  men¬ 
tal  tools  favored  by  one  of  them,  even 
when  programming  in  another.  For  exam¬ 
ple,  the  user  of  an  imperative  language 
such  as  Ada  or  C++  must  be  able  to  write 
in  a  functional  style,  acquired  through  prac¬ 
tice  with  Lisp  and  ML\  when  manipulating 
recursive  structures.  This  is  one  indication 
of  the  importance  of  learning  in-depth  a 
number  of  different  programming  lan¬ 
guages.  What  follows  summarizes  what  we 
think  are  the  critical  contributions  that 
well-established  languages  make  to  the 
mental  tool-set  of  real  programmers.  For 
example,  a  real  programmer  should  be  able 
to  program  inheritance  and  dynamic  dis¬ 
patching  in  C,  information  hiding  in  Lisp, 


tree  manipulation  libraries  in  Ada,  and 
garbage  collection  in  anything  but  Java. 
The  study  of  a  wide  variety  of  languages  is, 
thus,  indispensable  to  the  well-rounded 
programmer. 

Why  C  Matters 

C  is  the  low-level  language  that  everyone 
must  know.  It  can  be  seen  as  a  portable 
assembly  language,  and  as  such  it  exposes 
the  underlying  machine  and  forces  the  stu¬ 
dent  to  understand  clearly  the  relationship 
between  software  and  hardware.  Perfor¬ 
mance  analysis  is  more  straightforward, 
because  the  cost  of  every  software  state¬ 
ment  is  clear.  Finally,  compilers  (GCC  for 
example)  make  it  easy  to  examine  the  gen¬ 
erated  assembly  code,  which  is  an  excellent 
tool  for  understanding  machine  language 
and  architecture. 

Why  C++  Matters 

C++  brings  to  C  the  fundamental  concepts 
of  modern  software  engineering:  encapsu¬ 
lation  with  classes  and  namespaces,  infor¬ 
mation  hiding  through  protected  and  pri¬ 
vate  data  and  operations,  programming  by 
extension  through  virtual  methods  and 
derived  classes,  etc.  C++  also  pushes  stor¬ 
age  management  as  far  as  it  can  go  without 
full-blown  garbage  collection,  with  con¬ 
structors  and  destructors. 

Why  Lisp  Matters 

Every  programmer  must  be  comfortable 
with  functional  programming  and  with  the 
important  notion  of  referential  transparency. 
Even  though  most  programmers  find  imper¬ 
ative  programming  more  intuitive,  they  must 
recognize  that  in  many  contexts  that  a  func¬ 
tional,  stateless  style  is  clear,  natural,  easy  to 
understand,  and  efficient  to  boot. 

An  additional  benefit  of  the  practice  of 
Lisp  is  that  the  program  is  written  in  what 
amounts  to  abstract  syntax,  namely  the 
internal  representation  that  most  compilers 
use  between  parsing  and  code  generation. 
Knowing  Lisp  is  thus  an  excellent  prepara¬ 
tion  for  any  software  work  that  involves 
language  processing. 

Finally,  Lisp  (at  least  in  its  lean  Scheme 
incarnation)  is  amenable  to  a  very  compact 
self-definition.  Seeing  a  complete  Lisp 
interpreter  written  in  Lisp  is  an  intellectual 
revelation  that  all  computer  scientists 
should  experience. 

Why  lava  Matters 

Despite  our  comments  on  Java  as  a  first  or 
only  language,  we  think  that  Java  has  an 
important  role  to  play  in  CS  instruction. 
We  will  mention  only  two  aspects  of  the 
language  that  must  be  part  of  the  real  pro¬ 
grammer’s  skill  set: 


1.  An  understanding  of  concurrent  pro¬ 
gramming  (for  which  threads  provide  a 
basic  low-level  model). 

2.  Reflection,  namely  the  understanding 
that  a  program  can  be  instrumented  to 
examine  its  own  state  and  to  determine 
its  own  behavior  in  a  dynamically 
changing  environment. 

Why  Ada  Matters 

Ada  is  the  language  of  software  engineer¬ 
ing  par  excellence.  Even  when  it  is  not  the 
language  of  instruction  in  programming 
courses,  it  is  the  language  chosen  to  teach 
courses  in  software  engineering.  This  is 
because  the  notions  of  strong  typing, 
encapsulation,  information  hiding,  concur¬ 
rency,  generic  programming,  inheritance, 
and  so  on,  are  embodied  in  specific  fea¬ 
tures  of  the  language.  From  our  experience 
and  that  of  our  customers,  we  can  say  that 
a  real  programmer  writes  Ada  in  any  lan¬ 
guage.  For  example,  an  Ada  programmer 
accustomed  to  Ada’s  package  model,  which 
strongly  separates  specification  from 
implementation,  will  tend  to  write  C  in  a 
style  where  well-commented  header  files 
act  in  somewhat  the  same  way  as  package 
specs  in  Ada.  The  programmer  will  include 
bounds  checking  and  consistency  checks 
when  passing  mutable  structures  between 
subprograms  to  mimic  the  strong-typing 
checks  that  Ada  mandates  [6].  She  will 
organize  concurrent  programs  into  tasks 
and  protected  objects,  with  well-defined 
synchronization  and  communication 
mechanisms. 

The  concurrency  features  of  Ada  are 
particularly  important  in  our  age  of  multi¬ 
core  architectures.  We  find  it  surprising  that 
these  architectures  should  be  presented  as  a 
novel  challenge  to  software  design  when 
Ada  had  well-designed  mechanisms  for  writ¬ 
ing  safe,  concurrent  software  30  years  ago. 

Programming  Languages  Are 
Not  the  Whole  Story 

A  well-rounded  CS  curriculum  will  include 
an  advanced  course  in  programming  lan¬ 
guages  that  covers  a  wide  variety  of  lan¬ 
guages,  chosen  to  broaden  the  understand¬ 
ing  of  the  programming  process,  rather 
than  to  build  a  resume  in  perceived  hot  lan¬ 
guages.  We  are  somewhat  dismayed  to  see 
the  popularity  of  scripting  languages  in 
introductory  programming  courses.  Such 
languages  (Javascript,  PHP,  Atlas)  are 
indeed  popular  tools  of  today  for  Web 
applications.  Such  languages  have  all  the 
pedagogical  defaults  that  we  ascribe  to  Java 
and  provide  no  opportunity  to  learn  algo¬ 
rithms  and  performance  analysis.  Their 
absence  of  strong  typing  leads  to  a  trial- 
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and-error  programming  style  and  prevents 
students  from  acquiring  the  discipline  of 
separating  design  of  interfaces  from  speci¬ 
fications. 

However,  teaching  the  right  languages 
alone  is  not  enough.  Students  need  to  be 
exposed  to  the  tools  to  construct  large- 
scale  reliable  programs,  as  we  discussed  at 
the  start  of  this  article.  Topics  of  relevance 
are  studying  formal  specification  methods 
and  formal  proof  methodologies,  as  well  as 
gaining  an  understanding  of  how  high-reli¬ 
ability  code  is  certified  in  the  real  world. 
When  you  step  into  a  plane,  you  are  putting 
your  life  in  the  hands  of  software  which 
had  better  be  totally  reliable.  As  a  comput¬ 
er  scientist,  you  should  have  some  knowl¬ 
edge  of  how  this  level  of  reliability  is 
achieved.  In  this  day  and  age,  the  fear  of 
terrorist  cyber  attacks  have  given  a  new 
urgency  to  the  building  of  software  that  is 
not  only  bug  free,  but  is  also  immune  from 
malicious  attack.  Such  high-security  soft¬ 
ware  relies  even  more  extensively  on  for¬ 
mal  methodologies,  and  our  students  need 
to  be  prepared  for  this  new  world. ♦ 
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Note 

1 .  Several  programming  language  and  sys¬ 
tem  names  have  evolved  from 
acronyms  whose  formal  spellings  are 
no  longer  considered  applicable  to  the 
current  names  for  which  they  are  read¬ 
ily  known.  ML,  Lisp,  GCC,  PHP,  and 
SPARK  fall  under  this  category. 
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Bite  My  Bytes 


I’ve  been  doing  some  networking  lately.  Not  the  kind  of  net¬ 
working  that  gets  one  a  new  job,  but  computer  networking. 
Since  job  hunting  networking  is  now  done  on  a  computer,  some 
folks  may  not  see  the  difference,  so  just  take  my  word  for  it,  net¬ 
working  isn’t  necessarily  networking.  I’ve  been  doing  the  type  of 
networking  that  allows  computers  to  talk  to  each  other.  This  is 
what  some  people  would  call  network  administration  or  network 
engineering. 

There  are  many  different  types  of  people  in  the  networking 
field,  with  various  backgrounds.  Some  of  them  don’t  have  techni¬ 
cal  backgrounds,  and  technical  fields  have  their  own  language,  or 
vocabulary. 

While  working  on  an  infrared  project  some  years  ago,  I  dis¬ 
covered  that  there  existed  three  different  definitions  for  infrared. 
One  definition  exists  for  engineers,  which  was  defined  in  the 
Institute  for  Electronics  and  Electrical  Engineers  (IEEE)  stan¬ 
dard,  one  for  physics,  and  one  for  astronomers.  The  different  def¬ 
initions  evolved  separately  from  a  historical  perspective,  and  that  is 
understandable.  Astronomers  have  been  around  long  before  engi¬ 
neers. 

Now,  in  the  networking  literature,  I  find  a  particular  word,  the 
byte,  that  seems  to  be  taking  on  different  meanings.  As  an  engi¬ 
neer,  I  learned  that  a  byte  is  eight  bits.  Always.  A  nibble  is  four  bits. 
A  word  is  the  size  of  the  processor  data  line,  or  the  number  of 
data  bits  that  the  processor  takes  in  on  a  clock  cycle.  Sometimes 
this  is  the  size  of  the  internal  data  bus,  but  not  always.  When  I  talk 
about  a  byte,  I  mean  eight  bits.  When  some  one  else  talks  about  a 
byte,  I  think  they  mean  eight  bits.  As  the  March  Hare  told  Alice 
while  she  was  visiting  Wonderland,  ‘‘Then  you  should  say  what  you 
mean  [1].”  We  have  to  use  words  with  denotations  that  are  shared. 

In  several  books  that  I  have  been  reading  on  computer  net¬ 
working,  the  authors  don’t  seem  to  know  that  a  byte  is  eight  bits  — 
always.  Let’s  review  some  computer  science.  A  nibble  is  four  bits, 
a  byte  is  eight  bits,  and  a  computer  word  varies,  depending  on  the 
computer  architecture.  Some  early  computers  were  six  bit 
machines,  but  most  of  us  are  famiHar  with  the  eight  bit,  16  bit,  32 
bit,  and  now  64  bit  machines.  I  think  that  some  of  these  network¬ 
ing  authors  are  confusing  bytes  with  computer  words.  Could  that 
be  because  of  different  backgrounds  making  up  the  network  engi¬ 
neering  field?  Maybe  we  will  have  different  definitions  of  a  byte, 
one  from  the  engineering  field,  one  from  the  computer  scientists, 
and  one  from  certified  network  engineers.  Is  it  too  late  to  stop  this 
madness? 

One  book  gives  the  correct  definition  for  byte  on  page  83, 
then,  on  page  87,  defines  a  byte  as  seven  or  eight  bits,  depending 
on  whether  parity  is  used  [2] .  This  book,  which  is  very  good,  has 
a  glossary  where  a  byte  is  correctly  defined  as  eight  bits.  Perhaps, 
on  page  87,  the  author  is  confusing  using  bytes  with  using  the 
American  Standard  Code  for  Information  Interchange  (ASCII) 
character  set.  The  ASCII  is  a  seven-bit  code,  or  eight,  if  parity  is 
used.  A  byte  is  always  eight  bits. 

So,  what  does  dictionary.com  say?  To  my  horror,  some  of  the 
definitions  given  onHne  differ.  But  my  Webster’s  has  it  right  [3].  It 
defines  a  byte  as  “a  group  of  eight  binary  digits  processed  as  a  unit 
by  a  computer  and  used  especially  to  represent  an  alphanumeric 
character.”  And  Webster’s  definition  for  word,  under  2c,  has  “a 
number  of  bytes  processed  as  a  unit  and  conveying  a  quantum  of 
information  in  communication  and  computer  work.”  Webster’s 
does  not  have  a  technical  definition  of  a  nibble. 

Again,  to  my  horror,  I  found  that  the  IEEE  Standard  Glossary 


of  Software  Engineering  Terminology  did  not  commit  a  byte  to 
always  be  eight  bits.  The  definition  given  for  byte  and  the  one 
given  for  word,  was  very  similar,  and  a  definition  for  nibble  was 
not  given  at  all  [4]. 

I  think  that  because  a  byte  is  often  used  to  represent  an 
alphanumeric  character,  and  the  ASCII  code  is  7  or  8  bits,  depend¬ 
ing  on  whether  parity  is  used,  some  confusion  is  creeping  in  here. 
ASCII  is  being  replaced  by  Unicode,  which  can  use  as  many  as 
four  bytes  (or  32  bits).  See  <http://www.unicode.org>.  Now,  if 
four  bytes  are  32  bits,  how  large  is  a  byte? 

Some  of  these  networking  book  authors  don’t  think  that  a  byte 
is  always  eight  bits,  and  they  want  to  use  the  word  octet  to  convey 
an  eight  bit  quantity  [5].  I  was  just  wondering  if  the  definition  of 
byte  was  being  changed  because  of  differing  backgrounds  of  peo¬ 
ple  in  the  information  technology  workplace.  Before  reading  these 
books,  it  never  occurred  to  me  that  anyone  thought  that  a  byte  was 
anything  other  than  eight  bits. 

In  Salinger’s  book,  “The  Catcher  in  the  Rye,”  Holden  Caulfield 
tells  his  Httle  sister  Phoebe  what  he  would  like  to  do  with  his  life 
[6].  He  tells  of  picturing  these  children  playing  in  a  big  field  of  rye 
next  to  a  ckff  He  wants  to  stand  on  the  edge  of  the  ckff  and  catch 
any  kids  who  fall  over.  In  my  version  of  this  fantasy,  I  see  infor¬ 
mation  technology  professionals  wandering  about  in  a  big  field  of 
rye  wondering  if  a  byte  had  six,  seven,  or  eight  bits  in  it.  I  would 
be  there  to  assure  them  that  every  byte  has  eight  bits  and  only  eight 
bits.  It’s  the  size  of  a  computer  word  that  varies. 

—  Dennis  Ludwig 

dennis.ludwig@wpafb.a£mil 
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